hashCode über Zeit eindeutig?

[Oliver Specht]

Hi,
ich versuche gerade, in einer Klasse die hashCode Methode zu
überschreiben. Das Problem bei der Sache ist nur, daß es möglich sein
soll, die Objekte in jede erdenkliche persistente Art zu speichern und
nachher die Referenzierung der Objekte untereinander wieder herzustellen.

In meinem Fall speichere ich erstmal in eine XML Datei. Ich möchte auf
IDs etc. verzichten, also habe ich mir gedacht, ich speichere den
hashCode als Attribut. Der hashCode ist dann einfach die Zeit, wann er
zum ersten Mal abgefragt wurde oder er wird eben dann erzeugt, wenn das
Objekt abgespeichert wird, sofern er nicht vorher erzeugt wurde. Diese
Zeit kann ich dann einfach speichern und wieder herstellen.

Jetzt dann auch mal meine Frage:
Ist das sicher in dem Sinne, daß die hashCodes bei schneller Ausführung
hintereinander unterschiedlich sind? Welche Granulariät ist vonnöten?

Oder gibts was besseres?

Danke,
Oliver

[Lothar Kimmeringer]

Post by Oliver Specht
In meinem Fall speichere ich erstmal in eine XML Datei. Ich möchte auf
IDs etc. verzichten, also habe ich mir gedacht, ich speichere den
hashCode als Attribut. Der hashCode ist dann einfach die Zeit, wann er
zum ersten Mal abgefragt wurde oder er wird eben dann erzeugt, wenn das
Objekt abgespeichert wird, sofern er nicht vorher erzeugt wurde. Diese
Zeit kann ich dann einfach speichern und wieder herstellen.
Ist das sicher in dem Sinne, daß die hashCodes bei schneller Ausführung
hintereinander unterschiedlich sind? Welche Granulariät ist vonnöten?
Oder gibts was besseres?

Kommt drauf an, warum Du ueberhaupt hashCode ueberschreiben willst.
Wenn Du equals nicht ueberschreibst, warum willst Du dann Deinen
eigenen Algorithmus fuer die Ermittlung von hashCode implementieren.
Speicher einfach den Originalwert von hashCode weg:

public int hashCode(){
if (savedHashCode == -1){
savedHashCode = super.hashCode();
}
return savedHashCode;
}

Da der Hashcode in Object ueber die Systemreferenz gebildet
wird, sollte das doch dann genuegend fein granuliert sein.

savedHashCode muss natuerlich mit -1 initialisiert werden.
Man kann aber auch 0 als Kriterium verwenden...
Wenn Du Deine eigene equals-Methode hast, dann macht die
Zeit der Erzeugung der Instanz bei hashCode ueberhaupt keinen
Sinn und Du solltest Dir die API zu Object.equals nochmal
durchlesen.


Gruesse, Lothar

[Oliver Specht]

[..]

Post by Lothar Kimmeringer
Kommt drauf an, warum Du ueberhaupt hashCode ueberschreiben willst.
Wenn Du equals nicht ueberschreibst, warum willst Du dann Deinen
eigenen Algorithmus fuer die Ermittlung von hashCode implementieren.
public int hashCode(){
if (savedHashCode == -1){
savedHashCode = super.hashCode();
}
return savedHashCode;
}
Da der Hashcode in Object ueber die Systemreferenz gebildet
wird, sollte das doch dann genuegend fein granuliert sein.

Das stimmt, aber der hashCode ist bei Rückkonvertierung von XML zu Java
Objekt wieder ein anderer, daß eben die Systemreferenz gebildet wird und
diese ist immer anders :)

Post by Lothar Kimmeringer
savedHashCode muss natuerlich mit -1 initialisiert werden.
Man kann aber auch 0 als Kriterium verwenden...
Wenn Du Deine eigene equals-Methode hast, dann macht die
Zeit der Erzeugung der Instanz bei hashCode ueberhaupt keinen
Sinn und Du solltest Dir die API zu Object.equals nochmal
durchlesen.

Zu der equals-Methode brauche ich keine Infos, Danke :)

Oliver

[Lothar Kimmeringer]

Post by Oliver Specht
[..]

Post by Lothar Kimmeringer
Kommt drauf an, warum Du ueberhaupt hashCode ueberschreiben willst.
Wenn Du equals nicht ueberschreibst, warum willst Du dann Deinen
eigenen Algorithmus fuer die Ermittlung von hashCode implementieren.
public int hashCode(){
if (savedHashCode == -1){
savedHashCode = super.hashCode();
}
return savedHashCode;
}
Da der Hashcode in Object ueber die Systemreferenz gebildet
wird, sollte das doch dann genuegend fein granuliert sein.

Das stimmt, aber der hashCode ist bei Rückkonvertierung von XML zu Java
Objekt wieder ein anderer, daß eben die Systemreferenz gebildet wird und
diese ist immer anders :)

Ich habe die Existenz einer Set-Methode fuer savedHashCode
bei der Wiederherstellung aus dem XML als impliziz klar
vorausgesetzt.


Gruesse, Lothar

[Oliver Specht]

Lothar Kimmeringer wrote:

[..]

Post by Lothar Kimmeringer

Post by Oliver Specht
Das stimmt, aber der hashCode ist bei Rückkonvertierung von XML zu Java
Objekt wieder ein anderer, daß eben die Systemreferenz gebildet wird und
diese ist immer anders :)

Ich habe die Existenz einer Set-Methode fuer savedHashCode
bei der Wiederherstellung aus dem XML als impliziz klar
vorausgesetzt.
Gruesse, Lothar

Ja, aber das stellt immer noch nicht sicher, daß der hashCode bei zwei
Objekten nicht derselbe ist, denn die Objekte könnten z.B. die selbe
Speicheradresse besitzen.

Oliver

[Lothar Kimmeringer]

Post by Oliver Specht

Post by Lothar Kimmeringer
Ich habe die Existenz einer Set-Methode fuer savedHashCode
bei der Wiederherstellung aus dem XML als impliziz klar
vorausgesetzt.

Ja, aber das stellt immer noch nicht sicher, daß der hashCode bei zwei
Objekten nicht derselbe ist, denn die Objekte könnten z.B. die selbe
Speicheradresse besitzen.

Die Referenznummer des Objekts wird aber unterschiedlich sein,
selbst wenn diese beiden Instanzen an der gleichen Stelle
im physikalischen Speicher sein sollten. Die Referenznummer ist
aber massgeblich fuer die Bildung des hashCodes, daher sollte
das zu keinen gleichen Hashcodes fuehren.

Die einzige Ausnahme, die mir bekannt ist, ist per Reflection
zurueckbekommene Primitivtypen. Deren Systemhashwert kann sich
innerhalb eines Marshallvorgangs wiederholen (gab dann in
der Applikation entsprechend nette Effekte, wenn nach dem
Unmarshallen aus 17 ploetzlich 4000 wurde ;-).


Gruesse, LOthar

[Paul Ebermann]

Post by Lothar Kimmeringer

Post by Oliver Specht

Post by Lothar Kimmeringer
Ich habe die Existenz einer Set-Methode fuer savedHashCode
bei der Wiederherstellung aus dem XML als impliziz klar
vorausgesetzt.

Ja, aber das stellt immer noch nicht sicher, daß der hashCode bei zwei
Objekten nicht derselbe ist, denn die Objekte könnten z.B. die selbe
Speicheradresse besitzen.

Die Referenznummer des Objekts wird aber unterschiedlich sein,
selbst wenn diese beiden Instanzen an der gleichen Stelle
im physikalischen Speicher sein sollten. Die Referenznummer ist
aber massgeblich fuer die Bildung des hashCodes, daher sollte
das zu keinen gleichen Hashcodes fuehren.

Und bei einem 64-Bit-System bist du aufgeschmissen.

Der Hashcode wird nicht notwendigerweise direkt aus
der "Referenznummer" berechnet. (Was ist eine
Referenznummer?)

Post by Lothar Kimmeringer
Die einzige Ausnahme, die mir bekannt ist, ist per Reflection
zurueckbekommene Primitivtypen.

Du meinst deren Wrapper-Objekte?

Post by Lothar Kimmeringer
Deren Systemhashwert kann sich
innerhalb eines Marshallvorgangs wiederholen (gab dann in
der Applikation entsprechend nette Effekte, wenn nach dem
Unmarshallen aus 17 ploetzlich 4000 wurde ;-).

Ich weiß ja nicht, was du da für komische Datenstrukturen
verwendest ...


Paul

[Tor-Einar Jarnbjo]

Post by Lothar Kimmeringer
public int hashCode(){
if (savedHashCode == -1){
savedHashCode = super.hashCode();
}
return savedHashCode;
}

Warum überschreibst du eine Methode mit einer neuen Methode, die genau das
gleiche tut wie die ursprüngliche Methode, dafür aber viel ineffizienter
arbeitet?

Gruß, Tor

[Lothar Kimmeringer]

Post by Tor-Einar Jarnbjo

Post by Lothar Kimmeringer
public int hashCode(){
if (savedHashCode == -1){
savedHashCode = super.hashCode();
}
return savedHashCode;
}

Warum überschreibst du eine Methode mit einer neuen Methode, die genau das
gleiche tut wie die ursprüngliche Methode, dafür aber viel ineffizienter
arbeitet?

Der Hashcode soll ja, wenn das Object aus XML wiederhergestellt
wird identisch mit dem in XML gespeicherten sein. Daher muss man
das ueber eine entsprechende Instanzvariable tun. Zweck ist ja,
dass man, wenn die gleiche Instanz ins XML muss, die gleiche
Instanz am Ende wieder an beiden Stellen steht. In JUnit-Sprache:

public void testMarshallingUnmarshalling(){
MyObject o1 = new MyObject();
MyObject o2 = o1;
MyObject o3 = new MyObject();

Object[] arr = new Object[]{o1, o2, o3};

Object[] testarr = (Object[]) unmarshal(marshal(arr));

assertSame(testarr[0], testarr[1]);
assertNotSame(testarr[1], testarr[2]);
}

Stimmt's Oliver?


Gruesse, Lothar (der auch schon mal einen XML-basierten
Marshaller/Unmarshaller implementiert hat, bei dem obiger
Testcase durchlaeuft)

[Oliver Specht]

Post by Lothar Kimmeringer
Der Hashcode soll ja, wenn das Object aus XML wiederhergestellt
wird identisch mit dem in XML gespeicherten sein. Daher muss man
das ueber eine entsprechende Instanzvariable tun. Zweck ist ja,
dass man, wenn die gleiche Instanz ins XML muss, die gleiche
public void testMarshallingUnmarshalling(){
MyObject o1 = new MyObject();
MyObject o2 = o1;
MyObject o3 = new MyObject();
Object[] arr = new Object[]{o1, o2, o3};
Object[] testarr = (Object[]) unmarshal(marshal(arr));
assertSame(testarr[0], testarr[1]);
assertNotSame(testarr[1], testarr[2]);
}
Stimmt's Oliver?

Stimmt :) Ich versteh nur nicht, warum das bei Dir läuft?! Jedes neu
erzeugte Objekt könnte doch bei der Standard hashCode() Methode einen
hashCode bekommen, der bereits in der XML Datei gespeichert ist und
schon hast Du beim dazuspeichern zwei "gleiche" Objekte.

Oliver

[Lothar Kimmeringer]

[JUnit-Test]

Post by Oliver Specht

Post by Lothar Kimmeringer
Stimmt's Oliver?

Stimmt :) Ich versteh nur nicht, warum das bei Dir läuft?!

Dein Unglauben laesst mich vermuten, dass Du das schon mal
knallen hast sehen?

Post by Oliver Specht
Jedes neu
erzeugte Objekt könnte doch bei der Standard hashCode() Methode einen
hashCode bekommen, der bereits in der XML Datei gespeichert ist und
schon hast Du beim dazuspeichern zwei "gleiche" Objekte.

Fuer die Ermittlung der Referenz nimmt man auch nicht den
hashCode, sondern den sogenannten Identity-Hashcode, der
mit dem Standard-Hashcode identisch ist. Die Aufgabe der
Virtual Machine ist es, dass keine zwei Identity-Hashcodes
zur Laufzeit identisch sind. Zwar kann zehn Minuten, nachdem
der GC eine Instanz abgeraeumt hat eine neue mit gleichem
Identity-Hashcode entstehen, nur duerfte Dich das beim
Marshallen ja eher weniger interessieren.

Wenn Du mehrere Marshallvorgaenge in eine XML-Datei
konkatenierst, mag das wiederum anders aussehen (wie
oben selbst festgestellt). Das ist bei mir nicht das
Szenario, daher kann das es nicht zu Duplikaten kommen,
sollte das bei Dir aber so sein, wirst Du neben dem
Identity-Hashcode noch etwas anderes hernehmen muessen
(z.B. einen Zaehler). Da kann es dann durchaus Sinn
machen, mit dem RMI-UUID zu arbeiten, wie schon woanders
festgestellt.

Wenn aber jeder Marshallvorgang zu einer dedizierten
XML-Datei fuehrt, wirst Du mit meiner gebrachten Methode
arbeiten koennen.


Gruesse, Lothar

[Reinhard Bellmann]

Hallo!

[...] sogenannten Identity-Hashcode, der
mit dem Standard-Hashcode identisch ist. Die Aufgabe der
Virtual Machine ist es, dass keine zwei Identity-Hashcodes
zur Laufzeit identisch sind.

Wo steht denn das?

Es stimmt auch nicht!

Nimm mal folgendes Programm:

public static void main(String[] args) {
Object[] o = new Object[10000];
for (int i = 0; i < 10000; i++) {
o[i] = String.valueOf(i);
}
for (int i = 0; i < 10000; i++) {
for (int j = i + 1; j < 10000; j++) {
int hi = System.identityHashCode(o[i]);
int hj = System.identityHashCode(o[j]);
if (hi == hj) {
System.out.println("Aaaaarrrgll!");
}
}
}

}

Es werden 10000 nicht-equals und erst recht nicht == Objekte erzeugt
(garantiert verschiedene Strings, die einfach die stringifizierten
Zahlen von 0 bis 9999 darstellen), dann wir jedes Objekt mit jedem
bezüglich System.identityHashCode verglichen. Kannst ja die Ausgabe noch
aussagekräftiger machen. Und Du wirst sehen: Es gibt mehrere Objekte mit
gleichen Identity-Hashcodes.
Alle Objekte existieren hier offenbar *gleichzeitig*.

Grüße
Reinhard

[Tor-Einar Jarnbjo]

Post by Lothar Kimmeringer
Der Hashcode soll ja, wenn das Object aus XML wiederhergestellt
wird identisch mit dem in XML gespeicherten sein. Daher muss man
das ueber eine entsprechende Instanzvariable tun. Zweck ist ja,
dass man, wenn die gleiche Instanz ins XML muss, die gleiche

Ok, hatte ich verpasst.

Gruß, Tor

[Paul Ebermann]

Post by Lothar Kimmeringer
Der Hashcode soll ja, wenn das Object aus XML wiederhergestellt
wird identisch mit dem in XML gespeicherten sein. Daher muss man
das ueber eine entsprechende Instanzvariable tun. Zweck ist ja,
dass man, wenn die gleiche Instanz ins XML muss, die gleiche
public void testMarshallingUnmarshalling(){
MyObject o1 = new MyObject();
MyObject o2 = o1;
MyObject o3 = new MyObject();
Object[] arr = new Object[]{o1, o2, o3};
Object[] testarr = (Object[]) unmarshal(marshal(arr));
assertSame(testarr[0], testarr[1]);
assertNotSame(testarr[1], testarr[2]);
}

Ich würde hier sogar erwarten (verlangen), dass
testarr[0] == testarr[1] ist. Aber was hat das
mit dem Hashcode zu tun?


Paul

[Torsten]

Post by Oliver Specht
Hi,
ich versuche gerade, in einer Klasse die hashCode Methode zu
überschreiben.
Ist das sicher in dem Sinne, daß die hashCodes bei schneller Ausführung
hintereinander unterschiedlich sind? Welche Granulariät ist vonnöten?

Hi,

ich hoffe, Dir ist klar, was Du da tust!
Wenn Du Deine Objekte in einer HashMap speicherst, (oder sie irgendwo in
einer HashMap gespeichert werden, ohne dass Du es weißt!), dann wird Dir
ein Aufruf von map.contains(obj) IMMER false zurückliefern, da Dein
Hashwert jedes Mal ein anderer ist (nach Deiner Definition)...

=> Schreib' Dir lieber eine eigene Methode für Deinen eigenen Hash-Wert
und lass die Java-Methoden für den Zweck, zu dem sie gedacht sind!

Gruß,

Torsten

[Oliver Specht]

Post by Torsten

Post by Oliver Specht
Hi,
ich versuche gerade, in einer Klasse die hashCode Methode zu
überschreiben.
Ist das sicher in dem Sinne, daß die hashCodes bei schneller
Ausführung hintereinander unterschiedlich sind? Welche Granulariät ist
vonnöten?

Hi,
ich hoffe, Dir ist klar, was Du da tust!
Wenn Du Deine Objekte in einer HashMap speicherst, (oder sie irgendwo in
einer HashMap gespeichert werden, ohne dass Du es weißt!), dann wird Dir
ein Aufruf von map.contains(obj) IMMER false zurückliefern, da Dein
Hashwert jedes Mal ein anderer ist (nach Deiner Definition)...
=> Schreib' Dir lieber eine eigene Methode für Deinen eigenen Hash-Wert
und lass die Java-Methoden für den Zweck, zu dem sie gedacht sind!

Hi Torsten,
mmh, also ich glaube, es ist nicht ganz klar, was ich machen will :)

Also ich möchte sowas wie einen persistenten, also dauerhaften HashCode
eines Objektes speichern. Ich will nicht jedesmal die Zeit neu schreiben
oder das Objekt neu erzeugen. Ich will folgendes machen:

public int hashCode()
{
if (this.hashCode == 0)
{
this.hashCode = (int) System.currentTimeMillis();
return this.hashCode;
}

return this.hashCode;
}

Und dieser Wert wird einfach in einer XML Datei zum entsprechenden
Objekt abgelegt, also ungefähr so:

<object hashCode="2398572934">


Beim Rückkonvertieren wird dann der hashCode aus dem XML Element wieder
ins Objekt geschrieben.

Oder gibts da irgendwelche Probleme?

Oliver

[Torsten]

Post by Oliver Specht
Also ich möchte sowas wie einen persistenten, also dauerhaften HashCode
eines Objektes speichern. Ich will nicht jedesmal die Zeit neu schreiben
public int hashCode()
{
if (this.hashCode == 0)
{
this.hashCode = (int) System.currentTimeMillis();
return this.hashCode;
}
return this.hashCode;
}
Und dieser Wert wird einfach in einer XML Datei zum entsprechenden
<object hashCode="2398572934">

das schaut doch gut aus...
solange der HashCode für die "Lebensdauer" (die musst Du für Dich selber
definieren!) des Objektes eindeutig ist, ist alles OK. DAS muss aber
sichergestellt sein.

kleiner Tipp: lass das erste "return" in Deinem Code weg! (das innerhalb
des if).

Gruß,

Torsten

PS: equals() und hashCode() hängen untrennbar zusammen! Lies mal die
Javadoc der beiden Methoden! Wenn Du hashCode() überschreibst, musst (!)
Du auch equals() überschreiben, wobei dabei im obigen Fall folgender
Code reicht:

public boolean equals(Object o) {
if (o instanceof YourClass == false) {
return false;
}

return this.hashCode == ((YourClass)o).hashCode;
}

[Oliver Specht]

Post by Torsten
das schaut doch gut aus...
solange der HashCode für die "Lebensdauer" (die musst Du für Dich selber
definieren!) des Objektes eindeutig ist, ist alles OK. DAS muss aber
sichergestellt sein.
kleiner Tipp: lass das erste "return" in Deinem Code weg! (das innerhalb
des if).

Äh, jo, kann man ja weglassen :) Ist schon so gedacht, daß es dauerhaft
bleibt usw. meine Frage war eher, ob das eineindeutig ist, wenn ich die
System.currentTimeMillis(); benutze oder ob da u.U. zwei Objekte
denselben hashCode bekommen könnten.

[..]

Post by Torsten
PS: equals() und hashCode() hängen untrennbar zusammen! Lies mal die
Javadoc der beiden Methoden! Wenn Du hashCode() überschreibst, musst (!)
Du auch equals() überschreiben, wobei dabei im obigen Fall folgender
public boolean equals(Object o) {
if (o instanceof YourClass == false) {
return false;
}
return this.hashCode == ((YourClass)o).hashCode;
}

Ja, ist mir klar. War aber wie gesagt gar nicht meine Frage ;-)

Danke für die Hilfe,
Oliver

[Marian Aldenhövel]

Hi,

Post by Oliver Specht
meine Frage war eher, ob das eineindeutig ist, wenn ich die
System.currentTimeMillis(); benutze

Das kann man klar mit nein beantworten. Es hängt davon ab, wie
schnell hintereinander diese Aufrufe erfolgen, und wie flott der
Rechner ist. Wenn es also heute funktioniert kann es morgen auf
die Nase fallen.

Sichere Dich ab, indem Du die Erzeugung dieser IDs in eine eigene
Klasse auslagerst. Dort kannst Du meinetwegen
System.currentTimeMillis() verwenden und davor jeweils eine
Millisekunde schlafen :-). Oder aber einfach noch was "dazurühren",
einen Zähler zum Beispiel.

Ciao, MM

[Oliver Specht]

Post by Marian Aldenhövel
Hi,

Post by Oliver Specht
meine Frage war eher, ob das eineindeutig ist, wenn ich die
System.currentTimeMillis(); benutze

Das kann man klar mit nein beantworten. Es hängt davon ab, wie
schnell hintereinander diese Aufrufe erfolgen, und wie flott der
Rechner ist. Wenn es also heute funktioniert kann es morgen auf
die Nase fallen.
Sichere Dich ab, indem Du die Erzeugung dieser IDs in eine eigene
Klasse auslagerst. Dort kannst Du meinetwegen
System.currentTimeMillis() verwenden und davor jeweils eine
Millisekunde schlafen :-). Oder aber einfach noch was "dazurühren",
einen Zähler zum Beispiel.
Ciao, MM

Puh, da nehm ich doch lieber die ID und dazu den von Bernd genanten UUID
Generator :)

Danke für die Hilfe!

Oliver

[Bernd Eckenfels]

Post by Oliver Specht
Äh, jo, kann man ja weglassen :) Ist schon so gedacht, daß es dauerhaft
bleibt usw. meine Frage war eher, ob das eineindeutig ist, wenn ich die
System.currentTimeMillis(); benutze oder ob da u.U. zwei Objekte
denselben hashCode bekommen könnten.

Ja das kann passieren. Mit synchronized und wait kannste das umgehen, aber
das klappt dann nur im gleichen classloader der gleichen VM. Wenn dir das
ausreicht ist gut.

Du musst dir allerdings dann auch klar sein, dass du die equals methode auch
die idenditaet zum Vergleich nimmt.

Ich persönlich würde ja lieber einen der freien ("echten") UUID Generatoren
nehmen.

Gruss
Bernd

[Oliver Specht]

Bernd Eckenfels wrote:

[..]

Post by Bernd Eckenfels
Ich persönlich würde ja lieber einen der freien ("echten") UUID Generatoren
nehmen.

Welcher ist denn da so sinnvoll oder gut? Am Besten ohne Library
Einbindung o.ä. Einfach nur ne Klasse. Ich habe auf die Schnelle mal die
hier gefunden:

http://www.uk-dave.com/bytes/java/uuidgen.shtml
http://www.doomdark.org/doomdark/proj/jug/

Oliver

[Bernd Eckenfels]

Post by Oliver Specht
Welcher ist denn da so sinnvoll oder gut? Am Besten ohne Library
Einbindung o.ä. Einfach nur ne Klasse. Ich habe auf die Schnelle mal die

Ich hab inzwischen nen eigenen, weil wegen support fuer mac (via system
property) und norm konforme umsetzung der unterschiedlichen uuid versionen.
Der is aber nicht offen.

Gruss
Bernd

[Mark Rose]

Post by Bernd Eckenfels

Post by Oliver Specht
Welcher ist denn da so sinnvoll oder gut? Am Besten ohne Library
Einbindung o.ä. Einfach nur ne Klasse. Ich habe auf die Schnelle mal die

Ich hab inzwischen nen eigenen, weil wegen support fuer mac (via system
property) und norm konforme umsetzung der unterschiedlichen uuid versionen.
Der is aber nicht offen.

Wenn man keine übermäßigen Anforderungen hat, tut java.rmi.server.UID
recht gut. Falls Du JDK 1.5 einsetzen kannst, hilft java.util.UUID.

Das ganze ist plattformunabhängig und recht schmerzlos und sollte für
normale (sprich einfache) Anwendungszwecke ausreichen.

Mark.

[Bernd Eckenfels]

Post by Mark Rose
Wenn man keine übermäßigen Anforderungen hat, tut java.rmi.server.UID
recht gut.

Ne ich brauch ne echte UUID wegen interoperability. Da gibt es einige
verschiedene versionen, die bits sind genormt.

Post by Mark Rose
Falls Du JDK 1.5 einsetzen kannst, hilft java.util.UUID.

Is keine Option bisher.

Post by Mark Rose
Das ganze ist plattformunabhängig und recht schmerzlos und sollte für
normale (sprich einfache) Anwendungszwecke ausreichen.

Ich hab nur komplexe :)

Gruss
Bernd

[Michael Schuerig]

Post by Bernd Eckenfels

Post by Mark Rose
Wenn man keine übermäßigen Anforderungen hat, tut java.rmi.server.UID
recht gut.

Ne ich brauch ne echte UUID wegen interoperability. Da gibt es einige
verschiedene versionen, die bits sind genormt.

http://jakarta.apache.org/commons/sandbox/id/
http://jakarta.apache.org/commons/sandbox/id/uuid.html

<Auszug>
A Universally Unique Identifier (UUID) is a 128-bit identifier described
in the IETF Draft Uuid Specification . Generators for version 1 and
version 4 UUID's are provided. The value held in a UUID is represented
by a specific hexadecimal format of the binary fields. An example UUID
string representation is: F81D4FAE-7DEC-11D0-A765-00A0C91E6BF6. A
cautionary note: there is no standard regarding binary representation
of a UUID other than its string format.
</Auszug>

Eignet sich das für deine Zwecke?

Michael

[Lothar Kimmeringer]

Post by Oliver Specht
Äh, jo, kann man ja weglassen :) Ist schon so gedacht, daß es dauerhaft
bleibt usw. meine Frage war eher, ob das eineindeutig ist, wenn ich die
System.currentTimeMillis(); benutze oder ob da u.U. zwei Objekte
denselben hashCode bekommen könnten.

System.currentTimeMillis ist plattformabhaengig. Unter Windows
wird der Wert AFAIR nur alle 20 ms aktualisiert, daher wuerde
ich davon ausgehen, dass Du regelmaessig gleiche hash-Werte
bekommst, weswegen ich eben in meiner ersten Antwort schon
die Verwendung von super.hashCode vorgeschlagen habe (Deine
Methode hashCode sieht doch sonst absolut identisch zu meiner
aus, oder nicht?)


Gruesse, Lothar

[Lothar Kimmeringer]

Post by Torsten
PS: equals() und hashCode() hängen untrennbar zusammen! Lies mal die
Javadoc der beiden Methoden! Wenn Du hashCode() überschreibst, musst (!)
Du auch equals() überschreiben, wobei dabei im obigen Fall folgender

Das stimmt so nicht, ist aber auch eher unwesentlich. Man
kann hashCode ueberschreiben, ohne dass eine Aenderung von
equals notwendig ist.

Post by Torsten
public boolean equals(Object o) {
if (o instanceof YourClass == false) {
return false;
}
return this.hashCode == ((YourClass)o).hashCode;
}

Und wo soll da der Unterschied zu Object.equals sein?
Wozu der Vergleich der hashCode-Instanzen direkt,
ein einfaches hashCode() == o.hashCode() haette es auch
getan.


Gruesse, Lothar

[Bernd Eckenfels]

Post by Lothar Kimmeringer
Und wo soll da der Unterschied zu Object.equals sein?
Wozu der Vergleich der hashCode-Instanzen direkt,
ein einfaches hashCode() == o.hashCode() haette es auch
getan.

ein X mit dem hashcode 1 ist halt kein Y mit dem hashcode 1.

Gruss
Bernd

[Lothar Kimmeringer]

Post by Bernd Eckenfels

Post by Lothar Kimmeringer
Und wo soll da der Unterschied zu Object.equals sein?
Wozu der Vergleich der hashCode-Instanzen direkt,
ein einfaches hashCode() == o.hashCode() haette es auch
getan.

ein X mit dem hashcode 1 ist halt kein Y mit dem hashcode 1.

Die zwei Fragen sind getrennt zu betrachten, da ich bei Torstens
Beipiel zu Object.equals keinen Unterschied gesehen habe.
Da wird Referenz a mit Referenz b verglichen. Die sind immer
eindeutig, so wie Olivers geplanter hashCode auch.

Die zweite Frage war dann, warum - wenn man die equals schon
so ueberschreiben muss - das ueber die Instanzvariablen
direkt machen muss (was ja ein Casten notwendig macht) und
nicht gleich den Aufruf der hashCode() verwendet. Dass man
vorher auf den Typ einer Instanz ueberpruefen muss, ist schon
klar, ich habe schon genug equals-Methoden ueberschrieben ;-)


Gruesse, Lothar

[Paul Ebermann]

Post by Torsten
das schaut doch gut aus...
solange der HashCode für die "Lebensdauer" (die musst Du für Dich selber
definieren!) des Objektes eindeutig ist, ist alles OK. DAS muss aber
sichergestellt sein.

Warum?

Lies noch einmal die Definition von hashcode().
Selbst ein konstanter Hashcode von 42 für alle
Objekte ist kein Verstoß gegen die Regeln - es
macht Effizienz der Hash-Tabellen kaputt.

[...]

Post by Torsten
PS: equals() und hashCode() hängen untrennbar zusammen! Lies mal die
Javadoc der beiden Methoden! Wenn Du hashCode() überschreibst, musst (!)
Du auch equals() überschreiben,

Nein. Es muss nur sichergestellt werden, dass die beide
zusammenpassen.

Post by Torsten
wobei dabei im obigen Fall folgender
public boolean equals(Object o) {
if (o instanceof YourClass == false) {
return false;
}
return this.hashCode == ((YourClass)o).hashCode;
}

Wenn man soetwas machen will, muss man wohl
wirklich die Eindeutigkeit sichern.

Aber wenn man die Eindeutigkeit hat, braucht
man auch die equals-Methode nicht zu überschreiben,
da das dann mit (this == o) identisch ist.


Paul

[Michael Schuerig]

Post by Oliver Specht
ich versuche gerade, in einer Klasse die hashCode Methode zu
überschreiben. Das Problem bei der Sache ist nur, daß es möglich sein
soll, die Objekte in jede erdenkliche persistente Art zu speichern und
nachher die Referenzierung der Objekte untereinander wieder
herzustellen.

Du willst also eine persistente ID für die Objekte haben, oder? Am
sichersten ist es, wenn du die einmal explizit vergibst und dann
beibehältst. Die ID kannst (soltest!) du dann auch als Wert von
hashCode() verwenden.

Man kann auch den generierten Hashcode als ID verwenden, das ist aber
riskant. Ob es funktioniert, hängt davon ab, wie der Hashcode berechnet
wird. Wenn an der Berechnung Objekte beteiligt sind, deren eigener
Hashwert sich aus ihrer Identität ("Speicheradresse") ergibt, dann ist
der Hashwert bei jeder Programmausführung unterschiedlich.

Ich habe die zweite Variante in einem Spielprojekt kürzlich verwendet,
würde aber ansonsten davon absehen. Die Anforderung, die dabei an
hashCode() gestellt wird, ist zu unoffensichtlich. Wenn später ein
anderer Programmierer an dem Programm arbeitet, ist die Gefahr groß,
dass er über diese verborgene Anforderung stolpert.

Michael

[Oliver Specht]

Post by Michael Schuerig

Post by Oliver Specht
ich versuche gerade, in einer Klasse die hashCode Methode zu
überschreiben. Das Problem bei der Sache ist nur, daß es möglich sein
soll, die Objekte in jede erdenkliche persistente Art zu speichern und
nachher die Referenzierung der Objekte untereinander wieder
herzustellen.

Du willst also eine persistente ID für die Objekte haben, oder? Am
sichersten ist es, wenn du die einmal explizit vergibst und dann
beibehältst. Die ID kannst (soltest!) du dann auch als Wert von
hashCode() verwenden.

Genau das will ich machen.

Post by Michael Schuerig
Man kann auch den generierten Hashcode als ID verwenden, das ist aber
riskant. Ob es funktioniert, hängt davon ab, wie der Hashcode berechnet
wird. Wenn an der Berechnung Objekte beteiligt sind, deren eigener
Hashwert sich aus ihrer Identität ("Speicheradresse") ergibt, dann ist
der Hashwert bei jeder Programmausführung unterschiedlich.

Mmmh, das habe ich mal angenommen und deswegen überlegt, einen eigenen
hashCode zu nehmen, aber wenns nicht anders geht, bzw. wenn das u.U.
Java Probleme bereitet, ist es sogar Mehraufwand und inkonsistent.

Post by Michael Schuerig
Ich habe die zweite Variante in einem Spielprojekt kürzlich verwendet,
würde aber ansonsten davon absehen. Die Anforderung, die dabei an
hashCode() gestellt wird, ist zu unoffensichtlich. Wenn später ein
anderer Programmierer an dem Programm arbeitet, ist die Gefahr groß,
dass er über diese verborgene Anforderung stolpert.

Da hast Du Recht. Ich dachte, ich komme um das Implementieren einer ID
herum, aber anscheinend ist das zu vage mit dem TimeStamp.

Danke für die Info!

Oliver

[Marian Aldenhövel]

Hallo,

Post by Oliver Specht
aber anscheinend ist das zu vage mit dem TimeStamp.

Mehrere Threads auf einer (Mehrprozessor-)Maschine könnten gleiche
Timestamps produzieren. Läufe des Programms auf mehreren verteilten
Maschinen ebenso.

Ciao, MM

[Bernd Eckenfels]

Post by Marian Aldenhövel
Mehrere Threads auf einer (Mehrprozessor-)Maschine könnten gleiche
Timestamps produzieren. Läufe des Programms auf mehreren verteilten
Maschinen ebenso.

In einer millisekunde kannst du hunerte Ojecte anlegen, auch mit einer CPU.
Und wenn dann die VM noch grobkörniger als millisekunden implementiert wirds
haarig.

synchronized bla() {
long newVal = oldVal;
do {
newVal = System.currentTimeMillis();
if (newVal != oldVal)
{
oldVal = newVal; return oldVal;
}
Thread.wait(1);
while(true);
}

Auf diese Weise bekommt man den "penalty" sleep nur bei schnellem aufruf.
Eventuell kann man auch yield statt wait nehmen.

Gruss
Bernd

[Paul Ebermann]

Post by Oliver Specht
ich versuche gerade, in einer Klasse die hashCode Methode zu
überschreiben. Das Problem bei der Sache ist nur, daß es möglich sein
soll, die Objekte in jede erdenkliche persistente Art zu speichern und
nachher die Referenzierung der Objekte untereinander wieder herzustellen.
In meinem Fall speichere ich erstmal in eine XML Datei. Ich möchte auf
IDs etc. verzichten, also habe ich mir gedacht, ich speichere den
hashCode als Attribut.

Was soll das für einen Zweck haben?
Wofür brauchst du einen Hashcode, der eine
Persistierung überlebt?

Wenn man eine Hashtabelle abspeichert, baut man sie
üblicherweise nach dem einlesen mit den neuen Hash-Werten
wieder auf.


Paul

[Oliver Specht]

Paul Ebermann wrote:
[..]

Post by Paul Ebermann
Was soll das für einen Zweck haben?
Wofür brauchst du einen Hashcode, der eine
Persistierung überlebt?
Wenn man eine Hashtabelle abspeichert, baut man sie
üblicherweise nach dem einlesen mit den neuen Hash-Werten
wieder auf.
Paul

Das Problem ist, daß ich die Repräsentation der Daten flexibel halten
will. Speicherung soll in XML, Text, SQL, Serialisiert etc. möglich sein.

Oliver

[Stefan Matthias Aust]

Post by Oliver Specht
Das Problem ist, daß ich die Repräsentation der Daten flexibel halten
will. Speicherung soll in XML, Text, SQL, Serialisiert etc. möglich sein.

Warum? Bringt das dem Kunden (falls du einen hast) einen zusätzlichen
Wert? Ansonsten klingt das ein bisschen nach YAGNI...

[Oliver Specht]

Post by Stefan Matthias Aust

Post by Oliver Specht
Das Problem ist, daß ich die Repräsentation der Daten flexibel halten
will. Speicherung soll in XML, Text, SQL, Serialisiert etc. möglich sein.

Warum? Bringt das dem Kunden (falls du einen hast) einen zusätzlichen
Wert? Ansonsten klingt das ein bisschen nach YAGNI...

Das Teil ist OpenSource, also kann jeder Kunde sein :)

Ist also eher YMGNI ;-)

Oliver

[Stefan Matthias Aust]

Post by Oliver Specht

Post by Stefan Matthias Aust
Warum? Bringt das dem Kunden (falls du einen hast) einen zusätzlichen
Wert? Ansonsten klingt das ein bisschen nach YAGNI...

Das Teil ist OpenSource, also kann jeder Kunde sein :)
Ist also eher YMGNI ;-)

Nein, das ist immer noch kein Argument. Für alle Eventualitäten planen
halte ich für einen zu aufwendigen Design-Stil, der sich häufig nicht
auszahlt. Was du mit "alles ist möglich" sagst, ist, dass du nicht
weisst, wie es am besten sein sollte. Also kannst du einfach eine
Lösung wählen und - gerade weil es Opensource ist - das später ändern,
sollte es sich herausstellen, dass das ursprüngliche Gefühl doch nicht
so gut war.

[Oliver Specht]

Post by Stefan Matthias Aust

Post by Oliver Specht

Post by Stefan Matthias Aust
Warum? Bringt das dem Kunden (falls du einen hast) einen zusätzlichen
Wert? Ansonsten klingt das ein bisschen nach YAGNI...

Das Teil ist OpenSource, also kann jeder Kunde sein :)
Ist also eher YMGNI ;-)

Nein, das ist immer noch kein Argument. Für alle Eventualitäten planen
halte ich für einen zu aufwendigen Design-Stil, der sich häufig nicht
auszahlt. Was du mit "alles ist möglich" sagst, ist, dass du nicht
weisst, wie es am besten sein sollte. Also kannst du einfach eine
Lösung wählen und - gerade weil es Opensource ist - das später ändern,
sollte es sich herausstellen, dass das ursprüngliche Gefühl doch nicht
so gut war.

Also im Moment existiert die Möglichkeit, das Ganze in XML und in SQL zu
speichern. Ausserdem wächst das Projekt gerade noch. Geplant(!) ist, daß
jede Speicherung möglich sein soll und jeder das nach seinen Wünschen
implementiert. Deswegen existieren auch Konverter, die abstrakt gehalten
sind und dann konkret implementiert werden müssen. Dazu gehört dann eben
auch eine eindeutige ID. Ob das nun der hashCode ist oder der primary
key oder ... ist egal.

Sagen wir, man möchte das in ein neues Speicherformat ablegen, dann
implementiert man die Methode getID() eben mit seinem eigenen
UUID-Generator oder dann doch über den hashCode oder was auch immer.

Es dreht sich hier auch nur um die ID, um das nochmal zu betonen, nicht
um den Rest der Daten.

Oliver

[Paul Ebermann]

Post by Oliver Specht

Post by Paul Ebermann
Was soll das für einen Zweck haben?
Wofür brauchst du einen Hashcode, der eine
Persistierung überlebt?
Wenn man eine Hashtabelle abspeichert, baut man sie
üblicherweise nach dem einlesen mit den neuen Hash-Werten
wieder auf.

Das Problem ist, daß ich die Repräsentation der Daten flexibel halten
will. Speicherung soll in XML, Text, SQL, Serialisiert etc. möglich sein.

Das ist keine Antwort auf meine Frage.

Wofür brauchst du einen Hashcode, der eine
Persistierung überlebt?

Paul

[Oliver Specht]

Post by Paul Ebermann

Post by Oliver Specht

Post by Paul Ebermann
Was soll das für einen Zweck haben?
Wofür brauchst du einen Hashcode, der eine
Persistierung überlebt?
Wenn man eine Hashtabelle abspeichert, baut man sie
üblicherweise nach dem einlesen mit den neuen Hash-Werten
wieder auf.

Das Problem ist, daß ich die Repräsentation der Daten flexibel halten
will. Speicherung soll in XML, Text, SQL, Serialisiert etc. möglich sein.

Das ist keine Antwort auf meine Frage.

Du hast impliziert, daß ich eine Hashtabelle abspeichern will. Jetzt
möchte ich aber auch andere Datenformate benutzen können.

Post by Paul Ebermann
Wofür brauchst du einen Hashcode, der eine
Persistierung überlebt?

Ich will lediglich eine eindeutige ID haben. Ob das nun der hashCode ist
oder was anderes, ist letztendlich egal. Der hashCode wäre eleganter
fand ich, da er eben genau einmal vorkommt/vorkommen darf und das Objekt
somit im gesamten Code "wiederzufinden" ist über die hashCode Methode.

Oliver

[Paul Ebermann]

Post by Oliver Specht

Post by Paul Ebermann

Post by Oliver Specht

Post by Paul Ebermann
Wenn man eine Hashtabelle abspeichert, baut man sie
üblicherweise nach dem einlesen mit den neuen Hash-Werten
wieder auf.

Das Problem ist, daß ich die Repräsentation der Daten flexibel halten
will. Speicherung soll in XML, Text, SQL, Serialisiert etc. möglich sein.

Du hast impliziert, daß ich eine Hashtabelle abspeichern will. Jetzt
möchte ich aber auch andere Datenformate benutzen können.

Ich wollte sagen, dass der einzige Grund, wo man einen
gleichbleibenden Hashcode brauchen könnte, der wäre,
dass man eine Hash-Tabelle abspeichert (in welchem Format
auch immer). Und das macht man üblicherweise so, dass man
nicht darauf angewiesen ist, dass der Hashcode gleichbleibt
(weil das eben normalerweise auch nicht der Fall ist).

Post by Oliver Specht

Post by Paul Ebermann
Wofür brauchst du einen Hashcode, der eine
Persistierung überlebt?

Ich will lediglich eine eindeutige ID haben. Ob das nun der hashCode ist
oder was anderes, ist letztendlich egal. Der hashCode wäre eleganter
fand ich, da er eben genau einmal vorkommt/vorkommen darf

Ein Hashcode ist im allgemeinen nicht eindeutig.

(Wenn man "Hash" wörtlich übersetzt, erhält man
"Häcksel" - die Herstellung eines Hashs ist also
mit Informationsverlust verbunden.)

Wenn du dir die Spezifikation ansiehst, siehst
du auch nur die andere Richtung:

gleiche Objekte ==> gleicher Hash

(Mathematisch ausgedrückt: .hashCode() faktorisiert
über der von .equals() gebildeten Äquivalenzrelation,
kann also auf den Äquivalenzklassen gebildet werden.)

Post by Oliver Specht
und das Objekt
somit im gesamten Code "wiederzufinden" ist über die hashCode Methode.

Ich würde vorschlagen, du nennst deine ID auch so.

Wenn du es wirklich eindeutig haben willst, brauchst du
sowieso mehr als 32 Bits, die dir ein Hash liefert.

(Dann kannst du auch gleich einen Menschen-lesbaren
String nehmen.)

Den Hashcode kannst du nachher aus der ID ausrechnen,
und verwendest ihn nur für das, wofür er gedacht ist -
für schnelle Zugriffe in einer Hash-Tabelle.


Paul

[Oliver Specht]

Paul Ebermann wrote:

[..]

Post by Paul Ebermann
Ich wollte sagen, dass der einzige Grund, wo man einen
gleichbleibenden Hashcode brauchen könnte, der wäre,
dass man eine Hash-Tabelle abspeichert (in welchem Format
auch immer). Und das macht man üblicherweise so, dass man
nicht darauf angewiesen ist, dass der Hashcode gleichbleibt
(weil das eben normalerweise auch nicht der Fall ist).

Ach deswegen. Naja, in meinem Fall gehts nur um ne Referenzierung
innerhalb der Datenstruktur, insofern sollte das schon eineindeutig sein
und da das die Zeit nunmal ist...

Post by Paul Ebermann

Post by Oliver Specht

Post by Paul Ebermann
Wofür brauchst du einen Hashcode, der eine
Persistierung überlebt?

Ich will lediglich eine eindeutige ID haben. Ob das nun der hashCode ist
oder was anderes, ist letztendlich egal. Der hashCode wäre eleganter
fand ich, da er eben genau einmal vorkommt/vorkommen darf

Ein Hashcode ist im allgemeinen nicht eindeutig.
(Wenn man "Hash" wörtlich übersetzt, erhält man
"Häcksel" - die Herstellung eines Hashs ist also
mit Informationsverlust verbunden.)
Wenn du dir die Spezifikation ansiehst, siehst
gleiche Objekte ==> gleicher Hash
(Mathematisch ausgedrückt: .hashCode() faktorisiert
über der von .equals() gebildeten Äquivalenzrelation,
kann also auf den Äquivalenzklassen gebildet werden.)

gleiche Objekte ==> gleicher Hash würde ja eigentlich reichen, wenn ich
den normalen hashCode nehme, kanns dann aber passieren, daß ich zweimal
denselben hashCode habe, wenn ich Teile der Daten noch nicht konvertiert
habe und neue dazuspeichere.

Post by Paul Ebermann

Post by Oliver Specht
und das Objekt
somit im gesamten Code "wiederzufinden" ist über die hashCode Methode.

Ich würde vorschlagen, du nennst deine ID auch so.
Wenn du es wirklich eindeutig haben willst, brauchst du
sowieso mehr als 32 Bits, die dir ein Hash liefert.
(Dann kannst du auch gleich einen Menschen-lesbaren
String nehmen.)
Den Hashcode kannst du nachher aus der ID ausrechnen,
und verwendest ihn nur für das, wofür er gedacht ist -
für schnelle Zugriffe in einer Hash-Tabelle.

So mach ichs, Danke für die Hinweise :)

Oliver