.equals() vs ==
Not so long into my career I too memorised a version of the oldest mantra in the Java developer interviewee book.
Something along the lines of:
== compares object references while .equals() compares whatever is defined in the overridden method of the class upon which it is invoked.
If no override is provided then it defaults to the Object.equals()
A few years later, when preparing for my first Oracle Java certification, I learned in a lot more detail about the subject and was able to get into detail about it and really shine in that part of the interview process or just use it as a casual pick up line.
Interestingly enough, about 20% of the people I interview nowadays, still, either don’t fully answer this question correctly or simply can’t get into enough detail for the role they’re applying.
It is a cliche to ask this question in an interview process but it saves you some time if you do it tactfully and early enough over a phone screening for example.
To my surprise I saw some String comparisons being done with == rather than .equals(). Call it lack of experience, trigger happy fixer, way to naive for my own sake or plain old arrogance I started making amendments to this code base only to see them rolled back by our CTO.
In hindsight, I should have guessed that someone who established a company with a ethos of Java Excellence wouldn’t simply have forgot to override the equals method. Double hindsight: even asking would have been less arrogant than plowing away with find and replaces.
A few days later, over what always felt like a family lunch, the 30 or so developers of Linkare got together for a very casual, fun and geek lunch where I finally had the opportunity to hear a very in depth explanation about why my code changes hadn’t been accepted.
Turns out that the particular project was performing as a java driver keeping a very tight, controlled and predictable communication with some lower level C code that handled the status and updates of some mechanical bits that in turn, served as remote laboratory experiments.
Since the JVM had ALL of its IO predicted and limited, the code was perfectly functional and correct to have used a == to achieve a whole level of performance that would have, otherwise, dissipated through a slightly longer call stack to invoke the equals method.
This technique works because of the particular way Strings are handled in pools in Java. You can read more about it here but essentially creating Strings is so common that implementing them with a flyweight pattern meant that the JVM could shave off loads of tiny bits of memory throughout the lifecycle of a running application.
I now have a more interesting story to tell when asked “what’s the difference between == and .equals()?”