Impact of code difference in Collection#contains() worth improving?
Ulf Zibis
Ulf.Zibis at CoSoCo.de
Fri Aug 29 19:54:31 UTC 2014
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 at 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.Zibis at cosoco.de <mailto: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
More information about the core-libs-dev
mailing list