RFR: updated draft API for JEP 269 Convenience Collection Factories

Stuart Marks stuart.marks at oracle.com
Mon Nov 9 20:36:35 UTC 2015

On 11/7/15 9:42 AM, Michael Hixson wrote:
> (Realizing that we're discussing details of a feature that doesn't
> exist (frozen arrays)...)
> It seems to me that as long as the callee invoked the method with
> comma-separated arguments instead of an array, then the callee can
> automatically be opted into frozen arrays.  They never had access to
> the array box in the first place.
> It also seems like the varargs method could defensively call
> array.clone() and expect a no-op (return this) implementation if the
> array was already frozen, and so both sides could automatically
> benefit from frozen arrays without recompilation.  No?

It's sort-of like this, but of course a bit more complicated. :-)

Like you said, one idea is that the callee unconditionally calls array.clone(). 
If the array is frozen, it's a no-op, but if the array isn't frozen, it gets an 
actual clone.

The caller can't safely change a comma-separated argument list into a frozen 
array, though. The callee might actually modify the varargs array. This is bad 
style, but it's legal, so it has to be accounted for. This is why the callee has 
to have some declaration that it doesn't modify the array, to let the caller 
know it can pass a frozen array.

And yes, this feature doesn't exist yet, so this is all speculative.


More information about the core-libs-dev mailing list