Ich habe zwei Fragen

1. Wenn wir Interface "Comparator" implementieren übernehmen und überschreiben wir nur eine von zwei seinen Methoden: compare(), equals() nehmen wir nicht. Bei der Interface-Implementierung müssen alle im Interface enthaltene Methoden überschrieben sein, oder mindestens mit einem leeren Rumpf in der Klasse stehen. Wieso dann kommt in diesem Falle keine Fehlermeldung?

2. Warum, wenn man eine Java-Application durch Refactoring umbenennt, läuft sie nicht mehr? (Es kommt zwar vorher eine Verwarnung)

Danke im Voraus
Ihr Egbrecht Rosenstengel

Ich habe zwei Fragen

1. Wenn wir Interface "Comparator" implementieren übernehmen und überschreiben wir nur eine von zwei seinen Methoden: compare(), equals() nehmen wir nicht. Bei der Interface-Implementierung müssen alle im Interface enthaltene Methoden überschrieben sein, oder mindestens mit einem leeren Rumpf in der Klasse stehen. Wieso dann kommt in diesem Falle keine Fehlermeldung?

jede Klasse erbt von der Klasse Object und hat damit automatisch die Operation equals() implementiert
(da in Object bereits implementiert)

2. Warum, wenn man eine Java-Application durch Refactoring umbenennt, läuft sie nicht mehr? (Es kommt zwar vorher eine Verwarnung)
Danke im Voraus
Ihr Egbrecht Rosenstengel

bei mir gehts (Eclipse?),
was möchtest/en du/Sie jetzt hören?

1. Wenn wir Interface "Comparator" implementieren übernehmen und überschreiben wir nur eine von zwei seinen Methoden: compare(), equals() nehmen wir nicht.

Wenn ihr equals() nicht redefiniert, solltet Ihr Euch aber auch nicht wundern, falls es später mal unerwartet zu Problemen kommt. Das mag gut gehen, aber irgendwann nutzt Ihr die Klasse in einem Kontext, in dem sich jemand darauf verlassen hat, daß die Regeln für Comparator eingehalten wurden, wie sie in der Klassendokumentation stehen.

to Slater

1. Frage - Danke, jetzt erledigt.
2. Frage - Bei mir läuft's nicht (Eclipse). Die Warnung lautet:" Manche Applikationen laufen nach dem Refactoring micht". Pure Neugier: warum? Im Quelltext bleibt alles gleich, nur Name ist anders.

wie gesagt, bei mir geht Refactorn,
die Fehlermeldung hat bei google keinen Treffer,
zu 'eclipse refactor problem' gibts allerdings einiges ;)

da kann ich jedenfalls nix schlaues zu sagen,
vielleicht eine zu neue Version?, 2.0.1 ist ok ;)

beim umbenennen hat man mehrere haken, die man setzen kann…

ich glaube es sind 3 stück, und man sollte in jedem fall den ersten und letzten setzen (der letzte schmeisst dann noch ne meldung, dass man vorher ne vorschau machen muss, was ja kein problem is)

auf die weise funktionierts bei mir wunderbar, weil ja alle referenzen und so weier geändert werden

1. Wenn wir Interface "Comparator" implementieren übernehmen und überschreiben wir nur eine von zwei seinen Methoden: compare(), equals() nehmen wir nicht.

Wenn ihr equals() nicht redefiniert, solltet Ihr Euch aber auch nicht wundern, falls es später mal unerwartet zu Problemen kommt. Das mag gut gehen, aber irgendwann nutzt Ihr die Klasse in einem Kontext, in dem sich jemand darauf verlassen hat, daß die Regeln für Comparator eingehalten wurden, wie sie in der Klassendokumentation stehen.

equals im comparator zu überschreiben ist grundsätzlich nicht nötig. das ist nur dafür da, zu entscheiden ob 2 comparatoren gleich sind.

Note that it is always safe not to override Object.equals(Object). However, overriding this method may, in some cases, improve performance by allowing programs to determine that two distinct Comparators impose the same order.

und nochmal zum refactoring. ein beliebtes problem beim refactoring unter windows ist, wenn man bei einer klasse, einem projekt oder einem package nur die gross-kleinschreibung ändert, aber der name ansonsten gleich bleibt.
dann versuch eclipse, eine neue datei mit dem gleichen namen, aber andere gross-kleinschreibung zu erzeugen, scheitert aber dran, dass der name für windows gleich ist.
und weil in java auch die schreibweise der dateien von bedeutung ist, passt dann der klassenname nicht mehr zum dateinamen => es geht nich mehr
(ein work-arround ist die klasse vorher anders zu nennen, z.b einen buchstaben anhängen) und dann nochmal refactor und den entgültigen namen wählen.)

equals im comparator zu überschreiben ist grundsätzlich nicht nötig.

Nicht nur das, mehr als das zu leisten was "equals()" standardmäßig macht wird in den meisten Fällen so gut wie unmöglich sein. Das zwei "Komparatoren" exakt die selbe Ordnung erzeugen, geht ja nicht aus irgendwelchen Attributen hervor. Höchstens noch, wenn man einen Komparator hat welchen man durch bestimmte Attribute "tunen" kann.

Zitat:
[ … ] However, overriding this method may, in some cases, improve performance by allowing programs to determine that two distinct Comparators impose the same order.

Sun sollte über diesen Absatz nochmal nachdenken. Die "some cases" sind wohl in homöopathischen Größenordnungen zu beziffern.

–
EP

equals im comparator zu überschreiben ist grundsätzlich nicht nötig. das ist nur dafür da, zu entscheiden ob 2 comparatoren gleich sind.

Yepp, mein Fehler.

Zum einen hatte ich im Kopf Comparator mit Comparable verdreht und zum anderen übersehen, daß auch dort ein passendes Redefinieren von equals() nur nötig ist, wenn man "consistent with equals" sein will, dies aber von Benutzern der Schnittstelle nicht erwartet werden darf.

2. Frage - Bei mir läuft's nicht (Eclipse). Die Warnung lautet:" Manche Applikationen laufen nach dem Refactoring micht". Pure Neugier: warum? Im Quelltext bleibt alles gleich, nur Name ist anders.

Im Original heisst es IIRC "Some skripts may not run (blah)". Ist auch klar, wenn im Skript steht "java Foo", die Klasse aber inzwischen Bar heisst, gehts halt nicht mehr.