RFR: updated draft API for JEP 269 Convenience Collection Factories
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
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