Discussion:
hashCode über Zeit eindeutig?
(zu alt für eine Antwort)
Oliver Specht
2004-10-27 18:06:43 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Lothar Kimmeringer
2004-10-27 18:44:03 UTC
Permalink
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
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Oliver Specht
2004-10-27 18:53:09 UTC
Permalink
[..]
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
--
email: oliver ät dol2day dot com
Lothar Kimmeringer
2004-10-27 23:32:38 UTC
Permalink
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
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Oliver Specht
2004-10-27 23:37:27 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Lothar Kimmeringer
2004-10-27 23:48:26 UTC
Permalink
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
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Paul Ebermann
2004-10-28 20:40:14 UTC
Permalink
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
--
Die Homepage von de.comp.lang.java: http://www.dclj.de
Pauls Package-Sammlung: http://purl.org/NET/ePaul/#pps
Tor-Einar Jarnbjo
2004-10-27 19:14:39 UTC
Permalink
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
2004-10-27 23:31:21 UTC
Permalink
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)
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Oliver Specht
2004-10-27 23:40:23 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Lothar Kimmeringer
2004-10-28 00:03:38 UTC
Permalink
[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
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Reinhard Bellmann
2004-11-01 21:13:45 UTC
Permalink
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
--
Reinhard Bellmann
Tor-Einar Jarnbjo
2004-10-28 06:45:20 UTC
Permalink
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
2004-10-28 20:42:59 UTC
Permalink
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
--
The Java Virtual Machine Specification:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html
Torsten
2004-10-27 18:58:50 UTC
Permalink
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
2004-10-27 19:12:28 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Torsten
2004-10-27 19:34:19 UTC
Permalink
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
2004-10-27 19:44:10 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Marian Aldenhövel
2004-10-27 19:56:01 UTC
Permalink
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
--
Marian Aldenhövel, Rosenhain 23, 53123 Bonn.
Fon +49 228 624013, Fax +49 228 624031.
http://www.marian-aldenhoevel.de
"I know you believe you understand what you think I said, but I'm
not sure you realize that what you heard is not what I meant."
Oliver Specht
2004-10-27 20:09:38 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Bernd Eckenfels
2004-10-27 20:00:20 UTC
Permalink
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
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Oliver Specht
2004-10-27 20:16:53 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Bernd Eckenfels
2004-10-27 20:27:21 UTC
Permalink
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
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Mark Rose
2004-10-27 22:30:47 UTC
Permalink
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
2004-10-28 00:20:31 UTC
Permalink
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
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Michael Schuerig
2004-10-28 07:19:42 UTC
Permalink
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
--
Michael Schuerig The usual excuse for our most unspeakable
mailto:***@schuerig.de public acts is that they are necessary.
http://www.schuerig.de/michael/ --Judith N. Shklar
Lothar Kimmeringer
2004-10-27 23:36:15 UTC
Permalink
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 E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Lothar Kimmeringer
2004-10-27 23:40:34 UTC
Permalink
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
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Bernd Eckenfels
2004-10-28 00:34:24 UTC
Permalink
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
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Lothar Kimmeringer
2004-10-28 16:45:17 UTC
Permalink
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
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Paul Ebermann
2004-10-28 20:49:20 UTC
Permalink
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
--
Alle meine Antworten, Feststellungen, Behauptungen
sind mit AFAIK und IMHO zu lesen und nicht in der
Luft- und Raumfahrt oder Atomindustrie zu verwenden.
Michael Schuerig
2004-10-27 19:27:37 UTC
Permalink
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
--
Michael Schuerig Those people who smile a lot
mailto:***@schuerig.de Watch the eyes
http://www.schuerig.de/michael/ --Ani DiFranco, Outta Me, Onto You
Oliver Specht
2004-10-27 19:37:57 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Marian Aldenhövel
2004-10-27 19:57:49 UTC
Permalink
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
--
Marian Aldenhövel, Rosenhain 23, 53123 Bonn.
Fon +49 228 624013, Fax +49 228 624031.
http://www.marian-aldenhoevel.de
"I know you believe you understand what you think I said, but I'm
not sure you realize that what you heard is not what I meant."
Bernd Eckenfels
2004-10-27 20:17:50 UTC
Permalink
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
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Paul Ebermann
2004-10-27 20:26:36 UTC
Permalink
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
--
Wem es darum zu tun ist, dauerhafte Achtung sich zu erwerben; [...] der würze
nicht ohne Unterlass seine Gespräche mit Lästerungen, Spott und Medisance und
gewöhne sich nicht an den auszischenden Ton von Persiflage.
Adolf Freiherr Knigge, Über den Umgang mit Menschen, 1.17
Oliver Specht
2004-10-28 11:30:36 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Stefan Matthias Aust
2004-10-28 15:31:19 UTC
Permalink
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...
--
Stefan Matthias Aust
Oliver Specht
2004-10-28 16:30:04 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Stefan Matthias Aust
2004-10-28 17:11:45 UTC
Permalink
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.
--
Stefan Matthias Aust
Oliver Specht
2004-10-28 19:08:42 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Paul Ebermann
2004-10-28 15:33:28 UTC
Permalink
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
--
Ich beantworte Java-Fragen per E-Mail nur gegen Bezahlung. Kostenpunkt
100 Euro pro angefangene Stunde. Bitte erwähne in der Anfrage, dass du
das akzeptierst, da ich sonst die E-Mail einfach ignoriere.
(In der Newsgroup fragen ist billiger und oft auch schneller.)
Oliver Specht
2004-10-28 19:46:13 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Paul Ebermann
2004-10-28 22:57:23 UTC
Permalink
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
--
Die Homepage von de.comp.lang.java: http://www.dclj.de
Pauls Package-Sammlung: http://purl.org/NET/ePaul/#pps
Oliver Specht
2004-10-29 12:31:12 UTC
Permalink
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
--
email: oliver ät dol2day dot com
Lesen Sie weiter auf narkive:
Suchergebnisse für 'hashCode über Zeit eindeutig?' (Newsgroups und Mailinglisten)
17
Antworten
Auflistungen - Kaum glaubbare Zeiten
gestartet 2005-12-20 07:56:50 UTC
microsoft.public.de.german.entwickler.dotnet.vb
63
Antworten
Datenstruktur gesucht für A*
gestartet 2005-08-29 07:09:19 UTC
de.comp.lang.java
7
Antworten
Hashcode - SHA256Managed
gestartet 2008-02-29 06:57:57 UTC
microsoft.public.de.german.entwickler.dotnet.vb
24
Antworten
eindeutige Ids
gestartet 2007-05-17 21:01:53 UTC
de.comp.lang.java
Suchergebnisse für 'hashCode über Zeit eindeutig?' (Fragen und Antworten)
4
Antworten
Wie sicher ist Javas hashCode ()?
gestartet 2014-03-07 13:33:28 UTC
sicherheit
6
Antworten
Der Chef zwingt mich, zu einem Team-Social-Event zu gehen, wenn ich sonst im Jahresurlaub wäre
gestartet 2015-09-02 19:13:38 UTC
arbeit
4
Antworten
Wie unterscheidet sich das Geräusch des Hals-Tonabnehmers vom Geräusch des Bridge-Tonabnehmers?
gestartet 2017-02-02 08:14:28 UTC
musik
10
Antworten
Stellen zwei Zeilen kopierten Codes ein Plagiat dar?
gestartet 2017-12-07 04:48:24 UTC
wissenschaft
4
Antworten
Ist es nach einem Telefoninterview in Ordnung, der Personalabteilung die technischen Fragen zu stellen, die mir während des Telefoninterviews gestell
gestartet 2015-09-02 22:45:04 UTC
arbeit
Nicht verwandte, aber interessante Themen
14
Antworten
Lohnt es sich jemals, eine Frage zu stellen, wenn Sie wissen, dass die Antwort "Nein" ist?
gestartet 2017-08-04 15:11:27 UTC
5
Antworten
Leute, die als Senior eingestellt wurden, aber eigentlich als Junior, wie können sie ihnen helfen?
gestartet 2018-06-28 22:24:03 UTC
13
Antworten
Was soll ich in meinem Lebenslauf sagen, wenn ich befördert wurde, weil ich die Codequalität zur Einhaltung der Fristen gesenkt habe?
gestartet 2020-04-01 10:21:15 UTC
6
Antworten
Recommendation letter in Germany (Arbeitszeugnis)
gestartet 2016-08-18 13:54:45 UTC
5
Antworten
Ist ein Lowball-Gehalt dann ein Teilzeitangebot für japanische Standardverhandlungen?
gestartet 2019-07-03 04:40:11 UTC
Loading...