Mai 2011 Archive

Ich war in den letzten Tagen gezwungen Eclipse mal wieder neu zu installieren und musste daher auch mal wieder meine Plugins durchforsten. Nach dem ich die üblichen Verdächtigen für Subversion, Maven und Tomcat recht schnell instlliert hatte, fiel mir aber doch auf das ein paar kleine aber für mich persönlich doch sehr hilfreiche Plugins fehlten:

• Zum einem habe ich MoreUnit nachinstalliert. Ein Plugin das es ermöglicht zwischen der zu testenden und der getesteten Klasse direkt hin und her zu springen. Da bei mir Testklassen nach der Maven Konvention immer im selben Package aber nicht im selben Verzeichnis liegen (Produktiv unter src/main/java, Testklassen unter src/test/java) ist es in Eclipse manchmal ziemlich umständlich hin und her zu springen. Das erleichert dieses Plugin ungemein.
• Zum zweiten habe ich das Grep Console Plugin installiert. Normalerweise verwenden ich slf4j um Logausgaben zu schreiben, bei der Entwicklung in der Regel auf die Console (Produktiv natürlich in ne Datei).  Wenn das Logging recht ausführlich ist, kann man die eine oder andere wichtige Ausgabe schnell mal übersehen. Mit dem Plugin kann man die Ausgaben anhand von regulären Ausdrücken farbig hinterlegen. So werden bei mir ERROR Meldungen sofort rot hinterlegt, und ausgaben die sich auf meinen aktuelle gerade in Entwicklung befindlichen Code beziehen fett gedruckt. Das spart mir die sonst gerne von Entwicklern verwenden ******** oder ähnlichen unschönen Ausgaben (die dann manchmal sogar commited werden).

Die Garbage Collection der JVM ist eine praktische Sache und ich glaube kaum ein Java Programmierer möchte da drauf verzichten. Allerdings hat die Bequemlichkeit seinen Preis, Memory Leaks und intensive Garbage Collection sind fast immer ein Nadelöhr wenn es um Performance geht. Daher gibt es im Netz eine ganze Menge Artikel wie Gargabe Collection funktioniert (und wie man daher seine Objekte verwalten sollte), vieles davon ist allgemeine Best Practice, aber manche Sachen unterscheiden sich auch von Herstelle zu Hersteller. Leider beziehen sich fast alle Artikel (die nicht gerade vom Hersteller der jeweiligen JVM stammen)  immer nur auf Sun (bzw. jetzt Oracle) Virtual Maschine und vernachlässigen das es mit der BEA und der IBM JVM noch zwei weitere verbreitete Virtual Maschines gibt, die aber Garbage Collection doch etwas anders lösen. Dynatrace hat diese Tage einen schönen Artikel veröffentlich, der die Gargabe Collection auf unterschiedlichen Systemen einmal bescheibt. Persönlich halte ich es übrigens für sinnvoll einmal zu verstehen wie Garbage Collection funktionier, halte aber wenig davon Java Code für eine spezielle JVM zu optimieren. Klar gibt es Best Practice (wenige Objekte, kurzer Lebenszyklus, keine zyklischen Abhängigkeiten...) aber Java Code sollte eigentlich auf jeder Plattform und damit auch auf jeder JVM laufen, wenn man zuviel an der Garbage Collection schrauben muss, hat man in der Regel schon bei der Architektur etwas falsch gemacht.

Ich bin heute eher zufällig auf Folien von Eberhard Wolff (Spring Source) gestoßen die er für die JAX 2009 gemacht hat, und habe erst beim zweiten Lesen festgestellt das die Folien bereits 2 Jahre alt sind. Es gibt ne Menge neue Frameworks, sogar neue Sprachen auf der Java Plattform aber die  typischen Java EE Probleme bleiben doch immer noch die selben. Das es 10 typische Probleme sind bleibt ja außer Frage, aber sind es auch die 10 häufigsten bzw. die 10 kritischsten?

In meinem Job habe ich relativ viel mit Kunden zu tun, die sich vor Jahren für eine IBM AS/400 als strategische Plattform entschieden haben. Häufig befindet sich ein Großteil der zentralen IT Systeme auf dieser Plattform, die insbesondere für ihre Zuverlässigkeite und Abwärtkompatibilität berühmt ist. Allerdings nähert sich die Zeit der Host / Terminal Systeme langsam aber sicher dem Ende, viele neue Anforderungen (sowohl fachliche als auch Useability Anforderungen) lassen sich mit klassischer Host Technologie einfach nicht mehr lösen. Die Migration ist aber oft schwierig, da nicht nur Programme umgeschrieben sondern ganze Programmierparadigma umgestellt werden. Nichts da von ist trivial oder geht mal eben nebenbei, daher bietet IBM jetzt auf der Entwickler Community Developerworks endlich eine Webseite zum Thema System i die als Einsteigsseite für Entwickler auf dieser Plattform gute Dienste leisten kann.