Maybe can check each hashCode to see how they calculate it
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Object.java
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java
Eric Bresie
ebre...@gmail.com (mailto:ebre...@gma
You are computing the hash on a compile time constant value, so that
value is itself a compile tiem constant, and can be deived from the
memory location where that constant gets allocated when the JVM starts
up. This works for strings as they are all internalized at compile time,
that is stored
It shouldn't change, String is supposed to be an immutable class. At least
for Oracle JDK 8, hash codes for String instances are based on a recurrence
relation on the Unicode character values, *a*(*n*) = 31*a*(*n* − 1) + char.
So if a String only contains a single character, its hash code should be
That loophole about different values from run to run is solely for the
default implementation of hashcode, which is based on the actual internal
implementation of the instance.
Consider:
class MyClass {
int val = 1;
public MyClass() {
}
}
MyClass c1 = ne
I ran into this, thinking it would be the same per execution, but it does
not work like that.
If you create a for loop doing something like...
String test = "Hello World!";
for(i = 0; i < 100; i++) {
System.out.println(test.hashCode());
}
You will get 100 identical values.
Run it again, you wil
State of now, the hashCode of a String is the same in between different
executions for (most) oracle vms.
That might change in the future and might not be correct for all vms out
there.
If you you want to go sure and be future safe, the only valid way I see, is
to create a utility method created i
On 06/05/2021 12:37, Christopher C. Lanz wrote:
It would be helpful if I could rely on hashCode*always* to return the
same integer for the same object.
What are you doing such that needs to be the case?
CJ