I’m a newbie to Java. Now I’m studying equals and == and redefinition of equals and toString.
I would like to use both the toString method that I have redefied and the default method that is inherited from the Object class.
I failed to use that super modificator to reach that method.
This is for educational purposes only. What I would like to get is more clear if you will have a look at the comments in my code.
Could you help me here?
My code is:
public class EqualTest{
public static void main(String[] args){
Employee alice1 = new Employee("Alice Adams", 75000, 1987, 12, 15);
//System.out.super.println(alice1);
Employee alice2 = alice1;
//System.out.super.println(alice2);
Employee alice3 = new Employee("Alice Adams", 75000, 1987, 12, 15);
//System.out.super.println(alice3);
System.out.println("alice1==alice2: " + (alice1==alice2));
System.out.println("alice1 == alice3: " + (alice1==alice3));
System.out.println("alice1.equals(alice3): " + alice1.equals(alice3));
}
}
class Employee{
...
public String toString(){
return getClass().getName() + "[name = " + name +
", salary=" + salary + ", hireDay=" + hireDay + "]";
}
}
Advertisement
Answer
Strictly speaking, you can’t print the address of an object in pure Java. The number that looks like an object address in the String produced by Object.toString() is the object’s “identity hashcode”. It may or may not be related to the object’s current address:
The specs do not say how the identity hashcode number is calculated. It is deliberately left unspecified.
Since the number is a hashcode, it cannot change. So even though it is (typically) related to an object address, that will be the object’s address at the time when the hashcode was first accessed. This could be different to its current address, and it will be different if the GC has moved the object since the first time the object’s identity hashcode was observed.
On a 64bit JVM (with a large enough heap size / not using compressed oops) addresses won’t fit into an identity hashcode number which is returned as an
int.
Anyhow, the way to get this number is to call System.identityHashCode(obj).
If you really want an object’s current address, you can get it using JNI and a native method (and some abstraction breaking), or by using methods in the Unsafe class (see How can I get the memory location of a object in java?). But beware that both of these approaches are non-portable. Also, the object addresses that they give you are liable to “break” when the GC runs which renders them problematic for many (probably most) potential use-cases.
For the doubters, this is what the Java 10 javadocs say on the “hashcode != address” point:
“(The hashCode may or may not be implemented as some function of an object’s memory address at some point in time.)”
Emphasis added. Indeed, with recent JVMs, the default algorithm does NOT derive the hashCode from a memory address at all. It has been that way since at least Java 7.
You can confirm this by including -XX:+PrintFlagsFinal in the command line options to find out what the hashcode flag defaults to, and then looking at the OpenJDK source code to see what it means. (The code is in the “vm/runtime/synchronizer.cpp” file in some versions, but YMMV.)