Laszlo,, you are a hero ! I downloaded the OpenJDK 11 and just copied the
entire folder into my NetBeans 8.2 RCP app (build on jdk8) and renamed the
jkd11 folder to "jre" - Voila ! I just love Java, it surprises me even
again and again even after coding for 2 decades with it. Of course, lots
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
Is there any way to customize how a Netbeans Platform application will perform
Window->Reset Windows?
Specifically, when this action is performed I want to open/close some of the
windows in their default positions depending on the current state of the
application. For example, if the applicatio
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
Hello,
I have received all the information I need, and you can get all of it in this
thread. It turns out, that even though all my tests resulted in identical
output of hashCode(), later implementations of the JVM might not use the same
function. Thus I will write my own hashCode functions. I d
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
Ahh, ok good point ! I will try running NetBeans with jdk 11 (OpenJdk) on
the Alienware and see how it goes. Thank you for your interest and
suggestion.
Bests
Bernd
On Thu, May 6, 2021 at 10:24 AM Laszlo Kishalmi
wrote:
> I'd put my bet on the JDK AWT VRAM handling, so when I suggested upgrade
I'd put my bet on the JDK AWT VRAM handling, so when I suggested upgrade
JDK, I meant upgrading it to a more recent version than 1.8. I'd Try JDK
11 first, if that's still do not work I'd test more recent ones...
On 5/6/21 8:02 AM, Geertjan Wielenga wrote:
Maybe Swing-specific, so try reproduce
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
Maybe Swing-specific, so try reproduce with another Swing app or create a
new small Swing app yourself to reproduce the problem.
Gj
On Thu, 6 May 2021 at 16:55, bruehlicke wrote:
> Thanx. Tried 1.8u202 (latest I can use without commercial license) and it
> happened as well after a while. Hmm ..
Thanx. Tried 1.8u202 (latest I can use without commercial license) and it
happened as well after a while. Hmm ... currently only on Alienware
laptop. ... wicket. Anyhow here running NetBeans on a Gaming laptop having
trouble ? It looks like a generic problem and hence just running NetBeans
shoul
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
Hello,
Oracle's documentation for hashCode asserts:
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. T
14 matches
Mail list logo
