Sized

Kevin Bourrillion kevinb at google.com
Fri Nov 30 10:25:27 PST 2012


When I tried it you can go up to MAX_VALUE - 5.


On Fri, Nov 30, 2012 at 1:18 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> I've removed Sized from the implementation (since it is not adding the
> value it was supposed to) and have started migrating the streams methods to
> use longs for all size-related things.
>
> Obviously, this is going to run into some difficulty at a few touch points:
>  - creating arrays
>  - indexing into arrays
>  - when Collection.size() lies (because it is clamped at MAX_INT)
>
> The only place where we *have* to create an array is toArray, so I think
> its pretty reasonable to throw an exception when you try and create too big
> an array.  The other times are when we're creating a fixed-sized result
> builder, in which case if the size is too big we can back off to a
> variable-sized one.  If Collection.size() tells us it has MAX_INT, we
> should probably treat that as answering "I don't know my size."  The middle
> case is likely to have a bug tail.
>
> How much less than MAX_VALUE is the largest array size?
>
>
> On 11/28/2012 7:19 AM, Doug Lea wrote:
>
>> On 11/27/12 19:50, Doug Lea wrote:
>>
>>  In other words, greater-than-int-sized
>>> collections are not a future possibility, but a reality that
>>> was a few years the subject of several collections bugfixes.
>>> That will also require stream bugfixes soon enough.
>>>
>>>
>> And to make this extra fun, the maximum array size
>> you can create (for toArray etc) is less than
>> Integer.MAX_VALUE. See the odd constructions
>> strewn around collection implementations that
>> try to cope with this, but must still throw
>> exceptions when coping fails. This will be needed
>> for stream methods as well, regardless of Size-related
>> APIs.
>>
>> -Doug
>>
>>
>>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com


More information about the lambda-libs-spec-observers mailing list