Forums Register Login

(answer == something) versus (answer.equals(something))

+Pie Number of slices to send: Send
I am working through The Art & Science of Jave--An Introduction to Computer Science by Eric S. Roberts. On page 146 he is trying to explain the difference between the equals method and the == operator with a string example. His code snippet example is:



The author points out that the first if statement is checking to see if the string object "yes" is exactly the same as the string answer "yes' that the user may type in. He says that these can never be the same. Instead, the second if statement checks to see whether the value of the program's string object "yes" is the same as the value of the user's inputted string object "yes", which is what I should be checking for. I think I see the author's point, but cannot help but think of the following:



I know that this works, but it is working with one of Java's primitive data types. Do these not count as objects? Would someone help me understand the difference between these two examples?
1
+Pie Number of slices to send: Send
Welcome to the Ranch.

That's the difference between value equality and object equality. The same character string may be represented by various String objects, so comparing for object equality to check for same values is bound to fail.

This is indeed different for primitives. Note that all primitive types have associated classes, though, and if you get your hands on a Boolean, Integer, Float etc. object, then the rules for comparing those are quite the same as for String. So, yes - primitives are not objects (although there is a process called auto-boxing, which converts a primitive to an object of its associated class automatically under certain circumstances, but as a beginner you should probably ignore that for the time being).
+Pie Number of slices to send: Send
Thanks, Ulf. That clarifies things nicely.
+Pie Number of slices to send: Send
And welcome to the Ranch

We have an FAQ about the == operator. There are four circumstances where it is respectable to use the == operator on reference types:-
  • 1: When one of the operands is an enum constant. It even says so in the Java Language Specification.
  • 2: When you are writing an equals method and you needn't go through the rigmarole of comparing this object's fields with this object's fields: obj == this ||...
  • 3: When testing for nullity obj == null
  • 4: I would never do this for real, but only wanted to find out what happens if… Remember: trying things to see what goes wrong is a good way to learn.
  • +Pie Number of slices to send: Send
    Campbell, thanks for the additional information.

    Campbell Ritchie wrote:...

    We have an FAQ about the == operator. There are four circumstances where it is respectable to use the == operator on reference types:-

  • 1: When one of the operands is an enum constant. It even says so in the Java Language Specification.
  • 2: When you are writing an equals method and you needn't go through the rigmarole of comparing this object's fields with this object's fields: obj == this ||...
  • 3: When testing for nullity obj == null
  • 4: I would never do this for real, but only wanted to find out what happens if… Remember: trying things to see what goes wrong is a good way to learn.


  • FAQ: I'm still in the process of finding my way around this site. I overlooked this FAQ. As a side note it took me a while till I found an explanation on what these "cows" are about!
    1) I'm not far enough along that I have encountered enum constants. I will keep this in mind.
    2) I'm not sure I understand this. Probably because I have not made it far enough into Java yet.
    3) I can see the value in this. I imagine this can help one avoiding generating an error condition.
    4) You'll be happy to know that I do this all of the time!
    +Pie Number of slices to send: Send
     

    Robert Stepp wrote: . . .
    1) I'm not far enough along that I have encountered enum constants. I will keep this in mind.

    You're welcome
    An enum is a useful feature introduced nearly ten years ago: the enumerated type. You can read about it in the Java Tutorials.


    2) I'm not sure I understand this. Probably because I have not made it far enough into Java yet.

    If you prove you are comparing an object with itself for equality, you do not need to look at all its fields or anything. You know an object must be equal to itself.


    3) I can see the value in this. I imagine this can help one avoiding generating an error condition.

    There are some places where you can avoid nulls and some where you can't. In the latter case a test for obj == null (or != as appropriate) saves no end of error conditions.


    4) You'll be happy to know that I do this all of the time!

    Good. As I said you learn better by trying things and having them fail than by most other means.
    Let's get him boys! We'll make him read this tiny ad!
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com


    reply
    reply
    This thread has been viewed 1849 times.
    Similar Threads
    reading from keyBoard
    Brainy Upload Bean.
    Help with ArrayList(s) and FileIO
    why does it tell me that there is else without if (java programming)?
    Exception in thread "main" java.lang.NullPointerException
    Thread Boost feature
    More...

    All times above are in ranch (not your local) time.
    The current ranch time is
    Mar 29, 2024 01:37:27.