Impact of code difference in Collection#contains() worth improving?

[Vitaly Davidovich]

Right, and people take advantage of Comparable spec to avoid branches (when
over/underflow isn't a concern).

Sent from my phone
On Aug 28, 2014 1:30 PM, "Louis Wasserman" <lowasser at google.com> wrote:

> Comparator is spec'd to be allowed to return any number, positive,
> negative, or zero, but indexOf is specifically spec'd to return -1.
>
> If an indexOf method returns a negative value other than -1, that is a bug;
> it is not a bug if a Comparator returns a number other than -1, 0, +1.
>
>
> On Thu, Aug 28, 2014 at 10:27 AM, Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:
>
> >
> > Am 27.08.2014 um 17:51 schrieb Martin Buchholz:
> >
> >  The ArrayList version saves one byte of bytecode, and is therefore very
> >> slightly better.  We should bless that version and use it consistently.
> >>
> >
> > +1
> > Additional argument:
> > The LinkedList code requires to load 32/64-Bit -1 into CPU. This may take
> > some time on some CPU and at least wastes memory footprint.
> > Additionally register pressure increases.
> > Vitaly, please correct me, if I'm wrong, just for learning more.
> >
> > Another advantage is that there is no problem if some implementation of
> > indexOf() erroneously returns another negative value than -1. I remember
> > some compare() implementations, which sometimes return different values
> > than only -1, 0, +1.
> >
> > -Ulf
> >
> >
> >  ArrayList:
> >>>
> >>>      public boolean contains(Object o) {
> >>>          return indexOf(o) >= 0;
> >>>      }
> >>>
> >>> LinkedList:
> >>>
> >>>      public boolean contains(Object o) {
> >>>          return indexOf(o) != -1;
> >>>      }
> >>>
> >>>
> >
>
>
> --
> Louis Wasserman
>