The behavior of "equals" method of Arrays.asList() implementation
 

Basically I wonder if it is safe to use equals for collections (and
junit's assertEquals in particular which in fact results in the
*.equals invocation).

One of collection instances I am working with is returned from
Arrays.asList(..) method invocation.
Sun JDK sources defines no equals method for
java.util.Arrays.ArrayList inner class so I guess it is not safe to
compare collections in that way.
Surprisingly, equals called from Arrays.ArrayList "magically" (I can't
find another word) checks the elements in the collection!
I tried to walk throug the sources by using "step into" in the
debugger, but it mysteriously transfer control to the equals method of
my class (and yes, I have JDK sources attached, e.g. I can walk
through implementation of certain String method).

So the first question is: whether it is safe to use equals for *all*
the JDK's collections?
The second question is whether JVM adds "hidden" implementation in
certain places and Arrays helper List implementation is one of those,
so I may expect Arrays.asList(...) implementation behave in the same
way on different JDKs?

Thanks in advance!

Re: The behavior of "equals" method of Arrays.asList() implementation
 

Alex J <vstrength@gmail.com> writes:
>So the first question is: whether it is safe to use equals for *all*
>the JDK's collections?

What is »safe« supposed to mean in this case?

The »equals« methods of the collections behave
as documented in their Java SE docs, just like
every other collection method does.

>The second question is whether JVM adds "hidden" implementation in
>certain places

The compiler sometimes adds constructors so that
the implementation behaves as specified in the
JLS, but never »equals« methods.

Re: The behavior of "equals" method of Arrays.asList() implementation
 

Eric Sosman wrote:
> Alex J wrote:
>> Basically I wonder if it is safe to use equals for collections (and
>> junit's assertEquals in particular which in fact results in the
>> *.equals invocation).
>>
>> One of collection instances I am working with is returned from
>> Arrays.asList(..) method invocation.
>> Sun JDK sources defines no equals method for
>> java.util.Arrays.ArrayList inner class so I guess it is not safe to
>> compare collections in that way.
>
> Look again. The nested class extends AbstractList, and
> inherits the equals() implementation from it.

Not only that, but
<http://download.oracle.com/javase/6/docs/api/java/util/List.html#equals(java.lang.Object)>
so of course it worked, and it had better be safe or the implementation is
fubared.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg

Re: The behavior of "equals" method of Arrays.asList() implementation
 

On Tue, 28 Jun 2011 02:19:02 -0700 (PDT), Alex J <vstrength@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>Basically I wonder if it is safe to use equals for collections (and
>junit's assertEquals in particular which in fact results in the
>*.equals invocation).

Every object implements equals. Sometimes it amounts to == which many
not be what you want.
--
Roedy Green Canadian Mind Products
http://mindprod.com
One of the curses of the computer age is manufacturers now design
home appliances to die on the very day the warranty expires.
It is deliberate waste in the service of mindless profit.

Re: The behavior of "equals" method of Arrays.asList() implementation
 

On 6/28/2011 6:18 AM, Stefan Ram wrote:
> Alex J<vstrength@gmail.com> writes:
>> So the first question is: whether it is safe to use equals for *all*
>> the JDK's collections?
>
> What is »safe« supposed to mean in this case?
>
> The »equals« methods of the collections behave
> as documented in their Java SE docs, just like
> every other collection method does.

The obvious answer.

>> The second question is whether JVM adds "hidden" implementation in
>> certain places
>
> The compiler sometimes adds constructors so that
> the implementation behaves as specified in the
> JLS, but never »equals« methods.

The compiler is not the JVM, but your interpretation may
be correct that his question included compiler.

Arne