Proposal: Large arrays
reinier at zwitserloot.com
Tue Mar 24 14:38:31 PDT 2009
Arrays are extremely ugly. They don't follow java's usual semantics at
all; they have a read-only field, which java normally doesn't have. I
don't actually consider 'length' a field at all. "length" just happens
to be java's first context sensitive keyword. They don't have a
sensible toString(), which is, well, "stupid" is being too kind,
really. Their type system is broken (covariance, which is wrong, see
generics), with a patchy runtime hack to make sure you can't actually
crash the JVM with it. They are extremely hard to use because they
don't grow on demand, and they have 0 useful methods, though some of
them have been squirreled away in java.util.Arrays.
I'd be more supportive of a proposal that excises the blight of arrays
from java altogether. Or, perhaps somewhat more realistically, a
retrofit to move arrays into the proper collections API, where they
have a bunch of useful methods, .length becomes deprecated and .size()
is preferred instead, they are instanceof List<T>, and at the very
least have halfway sensible hashCode(), equals(), and toString()
The point of this rant: I actually laughed when I read "Is there a
compelling reason for [length] to use a method rather than a field"?
Anything done with arays is beyond salvation in the ugliness department.
I think josh's point that existing APIs that deal with arrays are not
going to handle this correctly is a very good one, and making
overloaded methods (a 'large array' twin) can't be the right answer
either: A properly implemented library would then have 3 methods that
do the exact same thing - one for arrays, one for large arrays, and
one for lists... and while we're at it, at some future point,
undoubtedly one for large lists as well.
Like it? Tip it!
On Mar 24, 2009, at 19:03, james lowden wrote:
>> I don't think the source compatibility impact is that
>> large actually. Let's say *all* arrays can potentially
>> be 64-bit now. The existing code that uses an int
>> expression to index into the array will still index into the
>> same element and negative indexes will still cause an
>> exception. Now, how should the length field be set?
>> I'd guess it should saturate to Integer.MAX_VALUE for
>> oversize arrays and a new "long size()" method
>> could be added to return the full length.
> This I'd actually prefer over what I proposed (and, based on the
> response so far and the previous bug, what others would probably
> like as well); my main concern was not breaking the int "length"
> field; I'd slightly prefer the long size to be a field rather than a
> method, but that may just be due to that being how I'm used to
> obtaining the array size; if there's a compelling reason to use a
> method rather than a field for this, I'd be curious to hear it.
>> The JVM would need to be modified to handle the long
>> indexes of course; perhaps the wide bytecode prefix could be
>> put to use here.
> Looking at wide, it looks like applying it to the existing array
> instructions would be an option; I would favor that approach over my
> original idea, which chews up a whole slew of opcodes.
> I'll probably stew on the various suggestions for a while, and send
> out a revised version of the proposal.
More information about the coin-dev