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

[Ulf Zibis]

Am 28.08.2014 um 19:30 schrieb Louis Wasserman:
Comparator is spec'd to be allowed to return any number, positive, negative, or zero, but indexOf 
is specifically spec'd to return -1.

Yes, I know. I wanted to say, that from this knowing some developer might assume the same for 
indexOf when successfully using ArrayList@contains() with other negative value than -1.

If an indexOf method returns a negative value other than -1, that is a bug;

Yes, but how you suggest to deal with such a bug in existing code. If we would unify JDK code to 
LinkedList style, it would break such existing code. That's what I wanted to point on.

Does the original thread opener want to open a bug e.g. "Unify code of 
contains()"?
If not, the discussion doesn't make sense anymore.

-Ulf




On Thu, Aug 28, 2014 at 10:27 AM, Ulf Zibis <ulf.zi...@cosoco.de 
<mailto:ulf.zi...@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