0

We can compare two objects by overriding the equals/hashcode method in the respective class, but still, the two objects will be equal in the context of our written methods(equals/hashcode) only!

Even if we found out that the two objects have same values of all attributes, does this really mean anything beyond that? I mean, the two will be distinct objects according to the compiler/JVM, right? And I suppose they will also hold two different memory locations, isn't it?

(I am new to Java, so if I have said anything totally stupid, I'll appreciate if you can correct me. Or if you need clarity on anything, feel free to ask. But in light of the same fact, I request all that please don't ask me to totally change my question or its structure. Thanks in advance!)

amsquareb
  • 148
  • 10
  • 1
    You can define your equality any way you want it will mean just that. –  Jun 17 '16 at 17:53
  • 3
    Possible duplicate of [What is the difference between == vs equals() in Java?](http://stackoverflow.com/questions/7520432/what-is-the-difference-between-vs-equals-in-java) – user140547 Jun 17 '16 at 17:55
  • 1
    If by "mean anything", you mean "mean that they're the same object", then no. If by "mean anything", you mean "mean anything", then yes. It means exactly what you define it to mean. You need to ask more precise questions. – user2357112 Jun 17 '16 at 17:56
  • 8
    Suppose you've got two quarters - they are each independent objects, occupying their own space, and composed of their own materials/resources. What does equality of these two objects mean? It means they are both worth 25 cents (`equals`). They obviously aren't the same quarter (`==`). – trooper Jun 17 '16 at 18:03
  • It's useful to note that you can define `.equals()` to mean anything you want it to mean. EVEN IF those two objects are still considered "different" by the JVM/compiler/etc., _your `.equals()` method will always consider them equal_. So as long as you use your `.equals()` method, they're for all intents and purposes equal. And you get to decide what that means. Trooper has a great answer above - consider if you changed coins to be equal based on color instead of value. Then a nickel .equals a dime .equals a quarter, but not .equals a penny. Even though none of them are actually equivalent (==) – Jordan Kuhn Jun 17 '16 at 18:03

2 Answers2

0

Yes in theory it does not matter too much, but isn't that with all applications you write? But whenever I'm comparing an object, and I know it's refering to the same database record since the ID is the same (And the type), it's valuable for my code. You can make sure that your object is not already in a list for example, you can have two different instances in a list whilst you would want a list of unique representations of your database objects, there the .equals function would become usefull.

If you need to know if it's the exact same instance you should probably not override the .equals method. like said by others the important thing is that two strings which contain the same textual value for example:

function foo() {
    String bar = "I'm cool";
    String baz = "I'm cool";

    assertTrue(bar.equals(baz)); //true
    assertTrue(bar == baz); //false
}

Example might be wrong but this is the difference here. If overriding the equals method does not matter for the JVM, well yes the JVM does not have a conscience.

Have fun!

Mathijs Segers
  • 6,168
  • 9
  • 51
  • 75
0

So much confusion in your question and lack of coherence. You write:

We can compare two objects by overriding the equals/hashcode method in the respective class

No, you don't. You compare two objects when you are executing something like, for example:

    String firstString = "asdf";
    int result = firstString.compareTo("asdff");

You "compare" when you call the compareTo method on an object of a class that implements Comparable (firstString), passing another object ("asdff") as the actual parameter of the method. That's it, it's just a matter of names (the names of the types -- classes -- and the names of the methods).

For what concerns the difference between the equality operator (==) and the equals method, again, it's just a matter of definitions. The rules are defined here https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.21

Even if we found out that the two objects have same values of all attributes, does this really mean anything beyond that?

What objects? What types are these objects? What type are their attributes? It all depends on how they are implemented. The question is very ambigous but I would say that the answer is no anyway. Equality, in the context of a Java program (or any other language), does not mean anything beyond what the language specifications, and the code, define.

I suppose they will also hold two different memory locations, isn't it?

Example (If you do not understand the "assert" thing, check JUnit out. It just means "this has to be true/false"):

@Test
public void testCrazy()
{        
    Object firstObject = new Object();
    // now I have a reference on the stack (firstObject) that points to some memory 
    // location on the heap that holds some bytes representing an Object instance
    Object secondObject = new Object();
    // now I have another reference pointing to a DIFFERENT location on the 
    // heap
    boolean equalReferences = (firstObject == secondObject);
    // equalReferences is expected to be false
    assertFalse(equalReferences);

    // look, I make the first reference point to the locations held by the
    // second one (tha is what = does if applied to references)
    firstObject = secondObject;
    // now the 2 references are expected to pass the equality operator test
    assertTrue(firstObject == secondObject);

    // what if I override equals in a completely nonsense way?
    firstObject = new Object(){
        @Override
        public boolean equals(Object obj)
        {
            // no matter what, it always returns false.
            // does it make sense? Probably not in our common sense, but the
            // compiler won't complain
            return false;
        }
    };

    secondObject = firstObject;
    // now they do point to same same memory location, in fact
    assertTrue(secondObject == firstObject);

    // but if I call the overriden equals method:
    assertFalse(firstObject.equals(secondObject));

    // it is still failing even if I call equals on firstObject itself:
    assertFalse(firstObject.equals(firstObject));
}
Evil Toad
  • 3,053
  • 2
  • 19
  • 28