RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

[Zheka Kozlov]

I think you should use iterator() instead of listIterator(). See the
explanation here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052472.html

вт, 4 дек. 2018 г. в 12:23, Tagir Valeev <amaembo at gmail.com>:

> Hello!
>
> Thank you for your comments!
>
> Yes, deserialization will be broken if we assume that size is never 0.
> Also we'll introduce referential identity Collections.nCopies(0, x) ==
> Collections.nCopies(0, y) which might introduce slight semantics
> change in existing programs. Once I suggested to wire Arrays.asList()
> (with no args) to Collections.emptyList(), but it was rejected for the
> same reason: no need to introduce a risk of possible semantics change.
>
> I updated webrev with equals implementation and test:
> http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r2/
> Comparing two CopiesList is much faster now indeed. Also we can spare
> an iterator in the common case and hoist the null-check out of the
> loop. Not sure whether we can rely that JIT will always do this for
> us, but if you think that it's unnecessary, I can merge the loops
> back. Note that now copiesList.equals(arrayList) could be faster than
> arrayList.equals(copiesList). I don't think it's an issue. On the
> other hand we could keep simpler and delegate to super-implementation
> if the other object is not a CopiesList (like it's implemented in
> java.util.RegularEnumSet::equals for example). What do you think?
>
> With best regards,
> Tagir Valeev.
> On Tue, Dec 4, 2018 at 10:56 AM Stuart Marks <stuart.marks at oracle.com>
> wrote:
> >
> >
> > >> I believe it makes sense to override CopiesList.equals()
> > > Also: contains(), iterator(), listIterator()
> >
> > equals(): sure
> >
> > contains() is already overridden. Not sure there's much benefit to
> overriding
> > the iterators.
> >
> > s'marks
>