Sized

[Brian Goetz]

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