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.
