Reputation: 2917
Imagine two simple java applications. Both of them are implementing the same JAR file containting an enum file like this:
enum enum1{
value1;
}
In both the applications I print the enum1.value1´s hashcode.
System.out.print(enum1.value1.hashCode());
How does the JVM work since the hashcodes are not equal even if the JAR file that the two applications implement is the same?
Why are not the hashcodes equal since it is the same JAR file the both applications implement?
EDIT
I have two applications that access a database. They are run within the same JVM. I would like to implement a locking mechanism so that when application 1 is writing to the database, application 2 has to wait for its turn (that is when the lock has been released by application 1). My solution is, if possible, to make an interface that has some ReentrantLocks declared or an enum that should act as lock and is used by the two applications. But then the instance of the interface/enum should be equal in both the applications, because you can only synchronize the same object.
EDIT 2
This is the architecture:
App1.jar Commons.jar App2.jar
App1Main.class Commons.class App2Main.class
Both App1 and App2 includes Commons.jar. The commons.class is just a simple singleton class. In both App1 and App2 I print the commons instance hashcode:
System.out.println(Commons.getInstance().hashCode());
Both java applications are run like "java -jar app1" and "java -jar app2" so there are two processes when they are running.
But they print different hashcodes and that is, what I belive (correct me if I am wrong), because they have been loaded by different class loaders. But the mystic arrives when I print the classloader in both apps:
System.out.print(ClassLoader.getSystemClassLoader().hashCode());
Then the hashcode is equal in both applications.
Upvotes: 1
Views: 712
Reputation: 93
enum is just a key word which makes the declared type class(For example enum Day means you will be having a class like Day extends Enum), class is a simple Template to the object which will be constructed in J.V.M which has its own hash code so obviously when you create a new Object you will get new hash code that is the reason why you are getting new hash code reffer following link for more details....
http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html
observe "All enums implicitly extend java.lang.Enum. Since Java does not support multiple inheritance, an enum cannot extend anything else" this point clearly.
Upvotes: 0
Reputation: 20885
See the Javadoc for Object.hashCode()
The general contract of hashCode is:
Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.
If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables.
Also
This is typically implemented by converting the internal address of the object into an integer
So your result seems perfectly legitimate to me. If you need the hash code to be consistent, maybe you are doing it wrong, since the API is not intended to be used this way. Maybe you could tell your objective.
Upvotes: 1
Reputation: 6237
Think of JAR as static resource containing a recipe for an application which may be run. When the application is actually run, all the resources are loaded into computer's memory using rules specific for an operating system. These rules does not enforce classes to be loaded in the same virtual memory address.
Upvotes: 0
Reputation: 1500495
It's not clear whether you're talking about two applications within the same process or not. Even if you are, if those two applications have separate ClassLoader
instances loading the same jar file, the two enum types are different types as far as the JVM is concerned. If you want a single type within a process used by two applications, it has to be loaded by a single classloader.
Upvotes: 2