Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > The behavior of "equals" method of Arrays.asList() implementation

Reply
Thread Tools

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

 
 
Alex J
Guest
Posts: n/a
 
      06-28-2011
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!
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      06-28-2011
Alex J <(E-Mail Removed)> 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.

 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      06-28-2011
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
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      06-28-2011
On Tue, 28 Jun 2011 02:19:02 -0700 (PDT), Alex J <(E-Mail Removed)>
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.
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      07-22-2011
On 6/28/2011 6:18 AM, Stefan Ram wrote:
> Alex J<(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Insertion Sort : C++ implementation 100 times slower than C implementation sanket C++ 7 11-03-2011 05:00 AM
Rules for "undefined/implementation-defined behavior" Jon C Programming 1 11-08-2010 01:49 AM
Knowing the implementation, are all undefined behaviours become implementation-defined behaviours? Michael Tsang C Programming 54 03-30-2010 07:46 AM
Knowing the implementation, are all undefined behaviours become implementation-defined behaviours? Michael Tsang C++ 32 03-01-2010 09:15 PM
Implementation -defined behavior amit.codename13@gmail.com C Programming 16 06-07-2009 11:11 AM



Advertisments