Proposal: Large arrays

[Reinier Zwitserloot]

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()  
implementations.

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.


  --Reinier Zwitserloot
Like it? Tip it!
http://tipit.to



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.
>
> -JL-
>
>
>
>