Jump to content
  • Advertisement
Sign in to follow this  
Lode

equals in java

This topic is 4835 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

When you make a new class with some variables in it, will the equals method of java automaticly check all those variables to see if they have the same value, or do you have to overload the equals method for that? EDIT: actually, same question for the "clone" method :)

Share this post


Link to post
Share on other sites
Advertisement
If you have two class objects, then a == b will check them by reference - do they point to the same object in memory?. Java doesn't have pointers in the same way as C/C++, but this is effectively doing the same thing.

a==b will not take the contents of your instance variables into account.

However, a.equals(b) should - but only if you implement it correctly [wink]

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by Lode
EDIT: actually, same question for the "clone" method :)

I've just done a week long 'Advanced Java Programming' course here at work, we covered this. Stupid thing is I never remember the exact rules.

a = b should do a shallow copy, making both a and b point to the same object.

Cloning should do a deep copy and make two seperate, but identical (a.equals(b) type identical) instances. However, the bit I always have to look up is whether the default implementation does anything but split into two instances. I think you have to implement your own clone() method to provide a deep copy - as you, the programmer, are the only one who knows enough about the contents of your class to do this effectively.

Then you get into the issues where your class contains references to other classes, and you have to rely on them both implementing Cloneable and doing it correctly. lots of fun!

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
Quote:
Original post by Lode
EDIT: actually, same question for the "clone" method :)

I've just done a week long 'Advanced Java Programming' course here at work, we covered this. Stupid thing is I never remember the exact rules.

a = b should do a shallow copy, making both a and b point to the same object.

Cloning should do a deep copy and make two seperate, but identical (a.equals(b) type identical) instances. However, the bit I always have to look up is whether the default implementation does anything but split into two instances. I think you have to implement your own clone() method to provide a deep copy - as you, the programmer, are the only one who knows enough about the contents of your class to do this effectively.

Then you get into the issues where your class contains references to other classes, and you have to rely on them both implementing Cloneable and doing it correctly. lots of fun!

hth
Jack


1. I have never seen a = b being called a shallow copy (a references the same object as b in this case; in my opinion you should not call that copying an object). For all my knowledge the default implementation of clone() creates a shallow copy (this is where the expression belongs), that is a new instance of the type of b is created and all it's fields reference the same objects as b's. That's a very important limitation. Creating a deep copy is decidedly non-trivial in general (circular references for example).
2. The default implementation of equals (as defined in Object) just compares the references of two objects; meaning it is identical to a == b. Usually, classes will have a sensible equals method implemented (check the documentation for what that exactly means). However, for you own classes you have to write a sensible comparison method by yourself.
3. The contract of clone does not require x.equals(x.clone()) to be true (<href>http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#clone()</href>).

Share this post


Link to post
Share on other sites
If you don't implement or overload clone and equals yourself, what exactly will they do?

Because, when I overload them, they have to be consistent with a certain "Liskov" (who I don't like by the way)...

Share this post


Link to post
Share on other sites
Quote:
Original post by Lode
If you don't implement or overload clone and equals yourself, what exactly will they do?

Because, when I overload them, they have to be consistent with a certain "Liskov" (who I don't like by the way)...


The best would be to read the Java Doc entries for those two methods. They explain much more indepth what happens.

Share this post


Link to post
Share on other sites
If you don't overload the methods, then you get the implementations from Object (unless they have been overloaded somewhere along the class hierarchy). equals() is the same as == and clone() creates a new instance and copies bit per bit the contents of the original (a shallow copy as it's been called here). If you want anything else you need to override the methods. If you need to make an uncloneable class then you have to override clone() and make it throw an CloneNotSupportedException.

shmoove

Share this post


Link to post
Share on other sites
Quote:
Original post by shmoove
If you need to make an uncloneable class then you have to override clone() and make it throw an CloneNotSupportedException.
shmoove


Not true. The default implementation of clone() already throws that exception unless the class implements the Cloneable interface. You only have to overwrite the clone() method manually if your class implements Cloneable for hierarchical reasons or a super class had a custom clone() method implemented.

Share this post


Link to post
Share on other sites
Quote:
Original post by BitMaster
1. I have never seen a = b being called a shallow copy (a references the same object as b in this case; in my opinion you should not call that copying an object). For all my knowledge the default implementation of clone() creates a shallow copy (this is where the expression belongs), that is a new instance of the type of b is created and all it's fields reference the same objects as b's. That's a very important limitation. Creating a deep copy is decidedly non-trivial in general (circular references for example).

My mistake [embarrass], you're right - I was getting muddled up with terminology.

Cheers,
Jack

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!