Java HashLists vergleichen

[Martin240]

An der Stelle macht es keinen Unterschied, da der Datentyp Integer ist und der ist bekanntlich ein primitiver Datentyp. In beiden Fällen würde der Compiler meines Wissens nach erst die int-Werte aus der Wrapper-Klasse unboxen und dann den Vergleich zwischen den int-Werten machen. Ein Integer ist ja nichts anderes als ein "verpackter" int-Wert. Es kommt also aufs selbe raus.

Das gilt allerdings nur für primitive Datentypen! Sobald du eine neue Klasse erstellst und davon Instanzen erschaffst hast du verschiedene Möglichkeiten diese zu vergleichen. In diesem Fall liefern dir die Sachen verschiedene Ergebnisse zurück und zwar:

== schaut ob es das gleich Objekt ist, nicht der Wert der darin steht. Du kannst zwei Objekte mit den gleichen Parametern instanziieren, der Vergleich liefert dir aber false, da die Variablen auf unterschiedliche Objekte zeigen.

Die Equals-Methode wird von jedem Objekt geerbt, weil sie in der Object-Klasse selber definiert ist. Die Standardimplementation liefert dir das gleiche Ergebnis wie ==, aber du kannst die Methode überschreiben. In der Regel überschreibt man diese dann indem man alle Werte der Objekte vergleicht, in deinem Fall wäre das dann die Punkteklasse, die die x- und y-Werte beider Objekte vergleicht und ein entsprechendes Ergebnis zurückgibt. Bindest du die Equals-Methode ein, solltest du auch die hashCode()-Methode überschreiben, wie oben bereits erwähnt, da du sonst Probleme bekommst wenn du die Objekte in eine HashMap oder ein HashSet setzen willst.

Der Vollständigkeit halber gibt es auch noch ein Comparable-Interface, dass die Methode compareTo() vorschreibt und als Rückgabe -1, 0 und 1 erwartet. Dabei gibt es -1 zurück wenn der Wert der Variablen kleiner ist, 0 wenn er gleich ist und 1 wenn er größer ist. Achtung! Der Wert der Variablen ist nicht zu verwechseln mit dem Wert des übergebenen Objektes.

Ich hoffe das hilft dir etwas weiter

 

[IceMatrix]

http://download.oracle.com/javase/1.4.2/docs/api/java/util/AbstractSet.html#equals(java.lang.Object)

 

[cl0udt]

Ja, das hilft weiter Vielen Dank an alle!

 

[Killkrog]

Hat int[] eigentlich ne ordentliche hashCode-Methode? Weiß das wer? Sonst ist die Benutzung eines HashSets ja völlig unsinnig...

 

[Banthor]

Hat int[] eigentlich ne ordentliche hashCode-Methode? Weiß das wer? Sonst ist die Benutzung eines HashSets ja völlig unsinnig...

Nein, diese und di equals()-Methoden werden von Object geerbt und beide Methoden sind ungeeignet für HashSets oder HashMaps. Derjenige der die Aufgabe gestellt hat, hat entweder keine Ahnung oder sehr gute Gründe so einen Murks vorzugeben.

 

[Killkrog]

Nein, diese und di equals()-Methoden werden von Object geerbt und beide Methoden sind ungeeignet für HashSets oder HashMaps. Derjenige der die Aufgabe gestellt hat, hat entweder keine Ahnung oder sehr gute Gründe so einen Murks vorzugeben.

Quellen? Nicht falsch verstehen, ich bin auch deiner Meinung, dass es so ist, aber seine Programmiersprache kann man nie gut genug kennen

 

[Banthor]

Quellen? Nicht falsch verstehen, ich bin auch deiner Meinung, dass es so ist, aber seine Programmiersprache kann man nie gut genug kennen

Hmm, du willst, dass ich Dir eine Quelle nenne, die sagt, dass bei Java eine erbende Klasse alle Methoden der Superklasse vererbt bekommt, sofern sie diese nicht überschreibt?

-> Siehe beliebiges Java-Anfängerbuch


Oder willst Du eine Quelle die sagt, dass die Defaultimplementierung von equals und hashCode ungeeignet sind?

Hier der Code aus dem Sun-Quelltext für equals():

public boolean equals(Object obj) {
return (this == obj);
}

Objekte werden also nur dann als gleich betrachtet, wenn sie identisch sind. Mit inhaltlicher Gleichheit hat das nichts zu tun. Daher kann ein Set niemals doppelte Elemente aussortieren, weil es nicht feststellen kann, ob die Objekte "gleich" sind.


Bei Hashcode kann ich dir jetzt keinen Quelltext zeigen, da diese Methode native ist. Allerdings wird meines Wissens nur die Speicheradresse darin verwurstet. Der Inhalt des Objekts wird dabei nicht einbezogen. Du kannst Dir als Beweis mal ein Testprogramm schreiben, welches Dir zwei inhaltlich identische Objekte erstellt, du wirst feststellen, dass die hashCodes unterschiedlich sind. Das sollte nicht der Fall sein und deshalb muss man es selber implementieren.

 

[Killkrog]

Ich wollte eine Quelle, die zeigt, dass das Objekt 'int[]' (Ein Array ist ein eigenständiges Objekt) keine besondere Implementierung der hashCode()-Methode besitzt
Das ist selber Quellcode durchforsten kann ist schon klar

 

[Banthor]

Ich habe keine Quelle, aber das braucht man auch nicht unbedingt, indem man es testet:

Nein, Arrays besitzen offensichtlich keine besondere Implementierung und geben unabhängig von Ihrem Inhalt immer den gleichen Hashcode zurück:

    int[] test = new int[]{1, 2, 3};
    System.out.println(test.hashCode());
    test[0] = -1;
    System.out.println(test.hashCode());

Ergebnis:
In beiden Ausgaben erscheint der gleiche Wert, unabhängig vom Inhalt.


Das hätte mich auch gewundert, wenn Java hashCode für Arrays basierend auf den Inhalten berechnen würde. Aus zwei Gründen:

1. Ohne Kenntnis der Objektmember und deren Wertestreuung kann man keine gute Hashfunktionen schreiben.
2. Performance


Stattdessen hat Sun mit Java5 eine einfache Implementierung von hashCodes für Arrays nachgeliefert. Diese ist aber nicht in im Array-Objekt verankert. In der Klasse Arrays gibt es dafür deshalb nun jede Menge statische hashCode() Methoden.