A List implementation backed by multiple small arrays rather than the traditional single large array.

[Kevin L. Stern]

Apologies, please use this link instead; this way you do not need to
download the file (it displays as a document).

https://docs.google.com/Doc?docid=0Aabrz3MPBDdhZGdrbnEzejdfM2M3am5wM2Mz&hl=en

Regards,

Kevin

On Sun, Mar 28, 2010 at 7:28 AM, Kevin L. Stern <kevin.l.stern at gmail.com>wrote:

> Please ignore the lack of custom serialization, I'll certainly tidy up the
> code if there is interest in it.
>
>
> On Sun, Mar 28, 2010 at 6:55 AM, Kevin L. Stern <kevin.l.stern at gmail.com>wrote:
>
>> I put together the following class, ChunkedArrayList, in response to
>> Martin's request (excerpted from an earlier conversation on this web board)
>> below.
>>
>>
>> https://docs.google.com/leaf?id=0B6brz3MPBDdhMGNiNGIwMTQtMTgxMi00ODlmLTk4ZGYtOWY2NDE0M2E5M2Zl&sort=name&layout=list&num=50
>>
>> Thoughts?
>>
>> Regards,
>>
>> Kevin
>>
>>
>> On Tue, Mar 9, 2010 at 3:15 PM, Martin Buchholz <martinrb at google.com>
>> wrote:
>>
>>     It surely is not a good idea to use a single backing array
>>     for huge arrays.  As you point out, it's up to 32GB
>>     for just one object.  But the core JDK
>>     doesn't offer a suitable alternative for users who need very
>>     large collections.
>>
>>     It would have been more in the spirit of Java to have a
>>     collection class instead of ArrayList that was not fastest at
>>     any particular operation, but had excellent asymptotic behaviour,
>>     based on backing arrays containing backing arrays.
>>     But:
>>     - no such excellent class has been written yet
>>      (or please point me to such a class)
>>     - even if it were, such a best-of-breed-general-purpose
>>      List implementation would probably need to be introduced as a
>>      separate class, because of the performance expectations of
>>      existing implementations.
>>
>>     In the meantime, we have to maintain what we got,
>>     and that includes living with arrays and classes that wrap them.
>>
>>     Changing the spec is unlikely to succeed..
>>
>>     Martin
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100328/48354369/attachment.html>