Als Java Beispiele nannte Rod auf der einen Seite Known Bugs: Er hat "damals" ein Applet für Netscape geschrieben und einem Manager vorgestellt. Dieser fragte, warum etwas auf eien bestimmte Art implementiert sei. Rod's Antwort war, dass das ein Work Around für ein Known Bug wäre. Der Manager kam aus dem Main Frame Bereich und hatte ein echtes Problem damit, dass es einen Fehler gibt, den man kennt, aber nicht fixt.
Ein anderes Problem sind die vielen Updates: Innerhalb für Main-Frame-Verhältnisse recht kurzer Zeit werden Technologien geupdatet und dabei wird z.B. bei EJB von 1.1 auf 2.0 und von 2.0 auf 3.0 in kurzer Folge das Programmiermodell mehrfach geändert, was dann zu hohem Aufwand bei der Migration führt. Es kann nicht sein, dass man für jede neue Technologie den Code ändern muss, wenn man wirklich profitieren will. Aktuell gehen ja schon hier in Bezug auf EJB 3 die ersten Sachen in dieser Richtung los...
Das bedeutet auch, dass als Lösung Standards wie eben beispielsweise EJB nicht reichen, um die Code Basis von diesen Änderungen frei zu halten. Trotzdem arbeitet Interface21 an Standards mit, ein Beispiel ist SCA, wo es mal nicht nur um Java, sondern um SOA geht.
Wie dem auch sei: Hier geht es eben doch um Java und eine weitere Aussage war, dass ein guter Indikator dafür, was ein POJO ist, ein JUnit Test sein kann: Was man unit-testen kann, kann man auch als POJO bezeichnen.
Rod sieht auch Annotationen aus JDK 1.5 kritisch: Sie sind das neue tolle Spielzeug, dass jetzt überall verwendet wird. Ein sehr erstaunliches Beispiel ist AOP in Java EE 5 / EJB 3: Dort zeigt die Klasse selbst an, womit sie ergänzt werden soll. Das Ziel von AOP ist allerdings, Dinge zu zentralisieren, die sonst verteilt sind. Hier allerdings wird der Aspekt immer noch verteilt konfiguriert. Das ist zumindest ungewöhnlich... ¶ 12:41
