64-bit array functionality implemented via libraries?

[Mark Thornton]

Reinier Zwitserloot wrote:
> There is no expectation that inserting near the front of a large list 
> is going to be performant when employing an enormous list.
Some types of lists do support fast insertion anywhere. I question 
whether a large collection library should include a LargeArrayList at all.
> Wouldn't it be far more fruitful for the javac/JVM core time to figure 
> out how to make primitive generics work properly? With such a 
> construct, arrays can truly be relegated to a niche, and 
> ArrayList<byte> would be as fast as byte[], and require about the same 
> order of memory, instead of 9 to 17 times more depending on JVM. Such 
> a change undoubtedly means it can't be java.util.List, but instead a 
> new collections API, so while the opportunity is there, support for 
> primitives in generics is quite easy: Let a generics parameter 
> declaration explicitly mention that it supports primitives as well as 
> classes. Once you have the freedom of not being tied to retrofitting 
> existing classes, it's doable.
While it would be nice I came to the conclusion that this really ought 
to be done in the context of reifying generics. Otherwise you add the 
additional wart of generics involving primitives being (necessarily) 
reified while those involving Objects are not.
>
> Internally, for each mention of 'T', all variants are generated. The 
> above 'get(long idx)', therefore, translates to many methods: 
> Object(long idx), int(long idx), short(long idx), etcetera. Similarly, 
> an .add(T x) method would expand to many methods; add(Object), 
> add(int), add(boolean), etc.
Better to generate the variants on demand at runtime.

>
> My point isn't so much that this mail is a complete proposal for such 
> a system (it certainly isn't, and, indeed, I doubt such a proposal 
> would be even close to small enough to fit within Project Coin's 
> mission), but rather that jumping through hoops changing the language 
> itself seems short-sighted to me. The value of a long arrays proposal 
> (vs. just using libraries to do it) exists only because java currently 
> lacks something that is fixable and would have far more utility.
>
It seems that large arrays and large collections raise a whole host of 
issues which we can barely begin to consider in the scope of Coin.
If we want to restrict [] to collections, then we aren't ready to define 
big collections. A more general approach that allowed [] for any class 
that had get/set marked (annotated?) in some way could be used to 
provide large arrays that might later be implemented in a different way.

Regards,
Mark