RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty - (toArray spec)

[Jason Mehrens]

MIke,
 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. Jason
 
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.