RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty - (toArray spec)
martinrb at google.com
Fri Apr 25 16:12:45 UTC 2014
I think it's OK to return static empty arrays. Make the trivial spec
On Fri, Apr 25, 2014 at 8:27 AM, Jason Mehrens <jason_mehrens at hotmail.com>wrote:
> The inner T.V. lawyer in me has been trying and find some loophole that
> will allow returning the same empty array from toArray. The spec states
> "..no references to it are maintained by this collection". The Saul
> Goodman loophole is that "this collection" implies object member
> reference. Which means that returning an empty array held by static field
> would be legal under that interpretation.
> So that leaves the final hurdle which is that the spec states "...method
> must allocate a new array...". I don't see a way around that unless the
> spec is changed. I can appreciate the reluctance to change spec as you
> pointed out bellow.
> JM>The modification for toArray violates the List contract because the
> returned array must be safe (must use 'new' and must not retain
> reference). I think you'll have JM>to back out that change. Contract
> violation aside, the only case that I can see that might unsafe for an
> empty array would be acquiring the monitor of JM>EMPTY_ELEMENTDATA array.
> When we patched the Collections$EmptyXXX classes we avoided returning a
> cached empty array for this reason.
> MD>You are of course correct. Yet another reminder to avoid unnecessary
> promises when creating specifications. <sigh> The Collection.toArray()
> javadoc could have MD>been written to allow for a shared empty array but
> isn't and can't be changed to be allow for this. We did eliminate the
> requirement to return a "new" instance MD>some cases for
> String/CharSequence/StringBuilder/StringBuffer in
> https://bugs.openjdk.java.net/browse/JDK-7174936 and MD>
> https://bugs.openjdk.java.net/browse/JDK-8028757 that were similar to
> this but those changes for the most part were to sync the javadoc to the
> longstanding MD>actual behaviour.
More information about the core-libs-dev