Interview:Java Equals

Interview : Java Equals

I would go for

"Something".equals(MyInput);

in this case if MyInput is null then it won't throw NullPointerException

Here we are sure that the object on which equals() is going to invoke is NOT NULL.

And if you expect NullPointerException from your code to take some decision or throw/wrap it, then go for first.

There is no performance impact

Interview Question on java hashcode()

There can be two different elements with the same hashcode. So your answer is incorrect. The only thing guaranteed is that if two elements have different hashcodes then they are different. When two elements have the same hashcode then Java uses the equals to further differentation.

So the answer is one or two objects.

Interview question -- apparent duplicate in a Set

Default implementation of equals() method would compare two objects memory addresses and default implementation of hashCode() method would will be object's memory address. As we're creating 2 objects pointing to different memory locations, they will be different by default, unless we define the equality and hash code by overriding the 2 methods for the class. But if you try to add the same instance twice, there will only be one instance added to the set. Hope this is clear.

Is calling equals() on the same instance faster than on changing instances?

This question has a lot of dimensions; let's address them one by one:

Yes, polymorphism could translate into performance gains. Option 1 calls the same method repeatedly. Option 2 could theoretically invoke a different equals implementation during each call. Thus Option 1 becomes subject to "JIT" compilation much earlier.

But let's look into the "practical" relevance of the whole thing:

Looking at compiled bytecode is interesting; but not really that helpful in the real world; as there are two cases:

bytecode is just exected a few times - JIT doesn't kick. Does it make a difference then, if that method needs 500 or 600 ns to finish?
bytecode is executed often enough for the JIT to work on it. Then you have no idea what will come out of that anyway.

Beyond that:

if you would be concerned about performance in the real world ... then you use neither of those two options; because in the real world, you would make sure that this incoming collection would be a set. If contains() is such a common operation in your code that you start worrying about option 1 vs option 2, then you would for sure go for O(1) set operation instead!
and as we have seen, option 1 might occasionally perform better. And: it is easier to read (much less surprising than option 2). And it has a slightly different probabilities regarding NPEs.

Long story short: all the arguments are in favor for option 1. Clear winner here!

Finally: of course, benchmarking this is an interesting exercise; but keep in mind: correct benchmarking is hard!

Is CONSTANT.equals(VARIABLE) faster than VARIABLE.equals(CONSTANT)?

Interesting question. Here is the test I wrote:

public class EqualsTest {
    public static String CONST = "const";
    public void constEqVar(String var) {
        CONST.equals(var);
    }
    public void varEqConst(String var) {
        var.equals(CONST);
    }
}

Then I compiled it using javac: javac EqualsTest.java and disassembled it using javap: javap -c EqualsTest.

Here is the relevant snippet of javap output:

public void constEqVar(java.lang.String);
  Code:
   0:   getstatic       #2; //Field CONST:Ljava/lang/String;
   3:   aload_1
   4:   invokevirtual   #3; //Method java/lang/String.equals:(Ljava/lang/Object;)Z
   7:   pop
   8:   return

public void varEqConst(java.lang.String);
  Code:
   0:   aload_1
   1:   getstatic       #2; //Field CONST:Ljava/lang/String;
   4:   invokevirtual   #3; //Method java/lang/String.equals:(Ljava/lang/Object;)Z
   7:   pop
   8:   return

As you can see the only difference between theses 2 methods is order of operations: getstatic and then aload_1 in first case and aload_1 + getstatic in second case.

Pretty obvious that the execution time should not depend on this order.

The only reason to prefer const.equals(var) rather than var.equals(const) is to avoid NullPointerException.

Strings in Java : equals vs ==

First of all String.toString is a no-op:

/**
 * This object (which is already a string!) is itself returned.
 *
 * @return  the string itself.
 */
public String toString() {
    return this;
}

Second of all, String constants are interned so s1 and s2 are behind the scenes changed to be the same String instance.

str.equals(String) vs String.equals(str)

The only reason for using "String".equals(str) (which I find ugly) is laziness, as it saves you the need to check that str != null prior to calling str.equals("String").

Performance-wise there shouldn't be any difference. You are comparing two String instances either way.

Interview:Java Equals