Yes, ==
with objects is a reference comparison* (checks if the operands are references to the same object), while equals
is whatever the class involved defines it to mean (within the requirements documented for equals
). Some classes define equals
as being the same as ==
, including Java's arrays. (Because they don't override the default implementation from Object.equals
, which uses ==
.)
If you want to compare Java arrays based on the equality of their contents, you use Arrays.equals
instead.
Your experiment would have worked if you used a class that defined equals
in a useful way, you were just unlucky picking arrays. It's a bit tricky to find a class in the JVM to use for this experiment, because so many either don't implement equals
(like arrays) or could be confusing because there are several immutable classes which may reuse instances (although not if you explicitly use new
; but I don't want to go down a path of having you use new
with something you probably shouldn't, like String
; more on that here). I'm going to give up on picking a good example and use the slightly old class SimpleDateFormat
:
DateFormat a = new SimpleDateFormat("yyyy-MM-dd");
DateFormat b = new SimpleDateFormat("yyyy-MM-dd");
System.out.println(a == b ? "== Same" : "== Different");
System.out.println(a.equals(b) ? "equals Same" : "equals Different");
That outputs
== Different
equals Same
because SimpleDateFormat
defines equals
to check that the other object is also a SimpleDateFormat
with the same formatting.
Live example
Re your comment on the question:
I have someone the answer points but I only get the == part, if .equals is checking the content, how come the code didnt print "same" for the second if
Because equals
doesn't, necessarily, check content. It only does if a class overrides the default Object.equals
(which just uses ==
) and implements a content check. Arrays don't. (One could argue that they should have, but they don't.) Other classes, like SimpleDateFormat
and String
and Integer
and HashMap
do.
In essence: ==
is always a reference comparison. equals
may or may not be a contents comparison, depending on what class you're using it on.
So for instance, say we have this class:
class Example1
{
private int content;
Example1(int content) {
this.content = content;
}
public static void main (String[] args) throws java.lang.Exception
{
Example1 a = new Example1(42);
Example1 b = new Example1(42);
System.out.println(a == b ? "== Same" : "== Different");
System.out.println(a.equals(b) ? "equals Same" : "equals Different");
}
}
Since that class doesn't override equals
, you'll get the same answer ("Different") for both ==
and equals
. Live Example.
But if we override equals
to define what it would mean for two instances to be equal (in this case: because they have the same content):
class Example2
{
private int content;
Example2(int content) {
this.content = content;
}
@Override
public boolean equals(Object obj) {
if (obj == null || !obj.getClass().equals(this.getClass())) {
return false;
}
Example2 other = (Example2)obj;
return this.content == other.content;
}
@Override
public int hashCode() {
return this.content;
}
public static void main (String[] args) throws java.lang.Exception
{
Example2 a = new Example2(42);
Example2 b = new Example2(42);
System.out.println(a == b ? "== Same" : "== Different");
System.out.println(a.equals(b) ? "equals Same" : "equals Different");
}
}
Now equals
says two instances with the same content are the same, because the class defines what that means. Live Example. (Also note that when overriding equals
, you must override hashCode
, which is why I've done so above.)
* More generally, ==
tests if the values of its operands are the same. The value in the case of reference types is an object reference, and two object reference values are only the same when they refer to the same object are are only different when they refer to different objects (or one of them is null
; not referring to an object at all).