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

Martin Buchholz 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
modification.


On Fri, Apr 25, 2014 at 8:27 AM, Jason Mehrens <jason_mehrens at hotmail.com>wrote:

>   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.
>



More information about the core-libs-dev mailing list