Sized (original) (raw)

Brian Goetz brian.goetz at oracle.com
Fri Nov 30 12:57:19 PST 2012

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 MAXINT) 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 MAXINT, 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 MAXVALUE 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.MAXVALUE. 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

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