On 7/9/2010 5:15 AM, Eric Sosman wrote:
On 7/8/2010 9:11 PM, Patricia Shanahan wrote:
Arne Vajh?j wrote:
On 08-07-2010 17:35, Boris Punk wrote:
Integer.MAX_VALUE = 2147483647
I might need more items than that. I probably won't, but it's nice to
have
extensibility.
It is a lot of data.
I think you should assume YAGNI.
Historically, each memory size has gone through a sequence of stages:
1. Nobody will ever need more than X bytes.
2. Some people do need to run multiple jobs that need a total of more
than X bytes, but no one job could possibly need that much.
3. Some jobs do need more than X bytes, but no one data structure could
possibly need that much.
4. Some data structures do need more than X bytes.
Any particular reason to believe 32 bit addressing will stick at stage
3, and not follow the normal progression to stage 4?
None. But Java's int isn't going to grow wider, nor will the
type of an array's .length suddenly become non-int; too much code
would break. When Java reaches the 31-bit wall, I doubt it will
find any convenient door; Java's descendants may pass through, but
I think Java will remain stuck on this side.
In ten years, we'll all have jobs converting "legacy Java code"
to Sumatra.
I don't think the future for Java is anywhere near as bleak as you paint
it.
The whole collections issue could be handled by creating a parallel
hierarchy based on java.util.long_collections (or something similar for
those who don't like separating words in package names). It would
replicate the class names in the java.util hierarchy, but with long
replacing int wherever necessary to remove the size limits. It could be
implemented, using arrays of arrays where necessary, without any JVM
changes.
To migrate a program to the new collections one would first change the
import statements to pick up the new packages, and then review all int
declarations to see if they should be long. Many of the ones that need
changing would show up as errors.
Arrays are a worse problem, requiring JVM changes. The size field
associated with an array would have to be long. There would also need to
be a new "field" longLength. Attempts to use arrayRef.length for an
array with more that Integer.MAX_VALUE elements would throw an
exception. arrayRef.length would continue to work for small arrays for
backwards compatibility.
I suspect Eclipse would have "Source -> Long Structures" soon after the
first release supporting this, and long before most programs would need
to migrate.