3

Is it possible that following code prints "false"?

If it is possible that object of type Class may be loaded then unloaded and then reloaded during execution of program then this could print false ?

Is the situation same in android and "normal java" ?

    class Person
    {
      Integer age;
      Person(Integer age) {this.age=age;}
    }

    int v1;
    {
      Person p1 = new Person(5);
      v1 = System.identityHashCode(p1.getClass());
    }
    .
    .

    int v2;
    {
      Person p2 = new Person(10);
      v2 = System.identityHashCode(p2.getClass());
    }


    if (v1 == v2)
      System.out.println("true");
    else
      System.out.println("false");
heivik
  • 111
  • 5
  • 2
    @DaveNewton, I read the question that way the first time, too. But 1 -- he is looking at the identity of the class itself, and 2 - his question is about the lifecycle of the class. – Dilum Ranatunga Dec 04 '12 at 17:03
  • @DilumRanatunga Yep, I just realized that too--it's the hashcode of the class. I *was* misreading the code. – Dave Newton Dec 04 '12 at 17:05
  • This is a very interesting question. @heivik has done what he can to not introduce additional references to the `Person` class -- that is presumably why he's using the identity hashcode stand-in for direct identity comparison. I wonder if some `WeakReference` instances to `Person.class` would provide any additional insight. – Dilum Ranatunga Dec 04 '12 at 17:11

2 Answers2

1

If all the code (except the class definition of Person is in a single class I don't think it can get two different instances of the Person class.

If you use something like OSGI you can actually get the Person-class loaded multiple times by different classloaders, and their hashCodes would be different, so I guess:

Yes you can construct cases where this returns "false"

Since you don't keep a reference to the Person instances the class could in theory actually get unloaded, when the two instanciating pieces themselves get loaded via reflection and garbage collected afterwards. AFAIK nothing in the language specification prevents garbage collections of class definitions. This is tremendously important when you have e.g. a web container where you deploy new versions of classes all the time during development. If the old versions don't get garbage collected this will lead to memory issues.

See also:

Unloading classes in java?

How to unload an already loaded class in Java?

Community
  • 1
  • 1
Jens Schauder
  • 77,657
  • 34
  • 181
  • 348
0

This code should always print true. As you are pointing to the same class by using p1.getClass()

identityHashCode

public static int identityHashCode(Object x)
Returns the same hash code for the given object as would be returned by the default method hashCode(), whether or not the given object's class overrides hashCode(). The hash code for the null reference is zero.
Parameters:
x - object for which the hashCode is to be calculated
Returns:
the hashCode
Since:
JDK1.1

As per the description written above, it will give default hashCode value which is always be different in object instantiation...

Person is an instance of Class class, so P1.getClass and P2.getClass are pointing to same instance of class... So V1 == V2.

Vishal
  • 3,189
  • 1
  • 15
  • 18
  • 1
    In a normal piece of code this will print two, because there is just one instance of the Person class. Note, the code determines hashCodes of the Person class, not of the Person instances. – Jens Schauder Dec 04 '12 at 16:56
  • @JensSchauder I am sorry, but I did not get you. – Vishal Dec 04 '12 at 17:00
  • Please read the question again. I am interested if object of type Class may be loaded, unloaded and then reloaded during program execution (when the answer could be false). – heivik Dec 04 '12 at 17:03
  • the OP ist comparing hash codes of p1.getClass() and p2.getClass() this returns the same instance of Person.class as long as everything is using one classloader. – Jens Schauder Dec 04 '12 at 17:05
  • Actually I would need some official reference (again) how things are. I can not trust for single opinion. – heivik Dec 04 '12 at 17:07