Die Java-Oberklasse java.lang.Object hat zwei wichtige Methoden: equals() und hashCode(). Diese beiden Methoden sind sehr wichtig, wenn Klasseninstanzen verglichen werden sollen oder wenn Klassen mit Collections interagieren. Beide Methoden sollen immer zusammen implementiert werden (siehe auch den Artikel von Angelika Langner zu equals() und hashCode()). Eclipse kann nun beim Kompilieren eine Warnung oder einen Fehler von sich geben, wenn beim Überschreiben von equals() vergessen wurde, hashCode() ebenfalls zu überschreiben. Entsprechende Quick Fixes zum Erzeugen der fehlenden Methoden stehen natürlich auch zur Verfügung. Dummerweise ist dieses hilfreiche Feature in der Default-Einstellung nicht aktiviert, kann aber in den Preferences auf der Seite JAVA | COMPILER | ERROR/WARNINGS im Bereich POTENTIAL PROGRAMMING PROBLEMS eingestellt werden. Der bereits aus älteren Versionen bekannte Dialog zum Erzeugen von equals() und hashCode() wurde außerdem mit einer zusätzlichen Auswahlmöglichkeit ausgestattet, über die man steuern kann, ob die im generierten Code enthaltenen if-Statements als Block mit geschweiften Klammern generiert werden sollen.
toString()
Eine weitere sinnvolle Erweiterung ist der neue Dialog zum Generieren von toString()-Methoden. Erreichbar ist die Maske über das Source-Menü. Wie man in der unten stehenden Abbildung sehen kann, hat man zunächst die Möglichkeit festzulegen, welche Felder oder Methoden in der toString()-Methode ausgewertet werden sollen. Die große Anzahl an zusätzlichen Einstellungen, die direkten Einfluss auf den generierten Code nehmen (String aneinanderhängen oder über String Builder arbeiten? String über String.format formatieren oder ganz eigenes Format vorgeben?) runden den positiven Gesamteindruck dieser neuen Funktion ab.
case-Blöcke ohne break?
Ebenfalls in der Sektion POTENTIAL PROGRAMMING PROBLEMS findet sich die recht interessante Einstellung 'SWITCH' CASE FALL-THROUGH. Diese Einstellung ist in der Standardkonfiguration deaktiviert (Ignore). Wenn man hier entweder auf Warning oder Error umstellt, reagiert der Compiler, wenn in einem switch-Statement ein case-Block nicht mit break abgeschlossen wurde und zeigt eine Warnung oder einen Fehler an. Mit dieser Funktion kann man also recht schnell herausfinden, welche case-Blöcke womöglich nicht korrekt beendet wurden und daher fehlerhaft sind. Sie stört aber, wenn man an einer bestimmten Stelle den break ganz bewusst weglassen möchte. In Java 5 könnte man hier die Annotation @SuppressWarnings("fallthrough") verwenden. Mit der aktuellen Fassung der JDT gibt es nun ganz neu auch die Möglichkeit, dem Compiler mit Hilfe des Kommentars //-THROUGH mitzuteilen, dass der Durchlauf bzw. das Weglassen von break, an dieser Stelle explizit gewünscht ist. Interessant ist diese Alternative in Situationen, in denen keine Annotations zur Verfügung stehen oder diese nicht verwendet werden dürfen.
