nicht angemeldet
Hallo Biesterfeld,
Das war es, was ich mit dem Session-Wrapper meinte.
Ok, allerdings solltest Du dazu keinen brauchen. Probier erst mal aus, ob es auch so klappt. Du kannst das ja einfach Testen, indem Du für zwei Parameter der Session das selbe Objekt angibst und hinterher mit == prüfst, ob die Parameter noch identische Werte haben.
Müssen nicht. Aber das ist sowieso etwas, was ich mich immerwieder frage: Wann final und wann nicht?
Auf jeden Fall braucht man final, wenn die Eigenschaften nicht private sind. Sonst braucht man das nicht unbedingt und der vorteil ist nur, dass man die Eigenschaften nicht irgendwo doch versehentlich ändert, obwohl das nicht so vorgesehen war. Wenn man darauf Wert legt, muss man für die Serialisierung eben etwas mehr Aufwand betreiben.
Was mich am allermeisten an dem ganzen Konzept stört ist, dass der HashCode eines Objektes in der nativen Implementierung abhängig vom Zustand der assoziierten Felder ist, also ändere ich ein Feld, ändert sich auch der HashCode.
Nein, die Standardimplementierung von hashCode gibt einen eindeutigen Wert für jedes Objekt zurück, der sich für ein Objekt niemals ändert. Er ändert sich natürlich beim Deserialisieren, weil die Objekte dort neu erzeugt werden. Die Implementierung von HashMap u.ä. kann aber sicher damit umgehen.
Wenn Du irgendwo direkt mit Hashcodes arbeitest, musst Du das natürlich beachten.
Es gibt Objekte, bei denen der HashCode von veränderbaren Eigenschaften abhängt (ich meine bei StringBuffer ist das z.B. der Fall). Da muss man natürlich etwas aufpassen.
Grüße
Daniel