Sized

[Brian Goetz]

I've pushed something that has all 64 bit sizes and passes our tests 
cases.  But we have no tests for really big streams, and I'm sure we're 
sowing the seeds of a bug tail here.  But, better than burning int into 
yet another API.  Reviews welcome.

On 11/30/2012 1:18 PM, Brian Goetz 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
>>
>>