Alt und neu?

Wie andere Sprachen auch ändert Java von Version zu Version das eine oder andere, zum Beispiel das Handling der Generics. Java 5 hatte diese Container-Typangabe für Vektoren oder Ähnliches eingeführt, um für etwas mehr Typsicherheit zu sorgen. In Java 7 änderte sich deren Verhalten wieder.

Wer nun mit gleicher Codebasis Java-ME-Anwendungen für Handys entwickeln will, kämpft damit, dass ME auf Java 1.1 fußt, das die Generics noch nicht kannte. Dann kodiert der Entwickler nach altem Standard und muss mit Warnungen leben. Entwickelt er den Code aber unter Java 5 oder 6 und kommt später auf die Idee, eine Java-ME-Version zu bauen, muss er viel Code umschreiben.

Zum Teil unterscheiden sich die JVMs auch in der Speicherverwaltung, was dazu führen kann, dass die identische Applikation mit dem gleichen den Speicher begrenzenden Parameter unter JVM A einwandfrei läuft und unter JVM B mit vollgelaufenem Speicher abstürzt. 64-Bit-Systeme benötigen zum Beispiel mehr Platz im Heap, weil alle Zeiger doppelt so groß sind. Es ist zwar möglich, entsprechend mehr Speicher zu adressieren, aber auch das Verwalten des Speichers benötigt den doppelten Platz.

Auch bei der Wahl der Entwicklungsumgebung gibt es Feinheiten, die dazu führen, dass derselbe Quellcode in Eclipse funktioniert und sich daraus ein Paket bauen lässt, mit Ant und Javac aber nicht. Der Hintergrund ist, dass Eclipse einen eigenen Java-Compiler verwendet und dieser fehlerhafte Methoden einfach ausblendet. Um den eigenen Testaufwand gering zu halten, supporten daher viele Anbieter kommerzieller, in Java geschriebener Produkte nur genau eine JVM-Version.

Testen, testen, testen

Java-Entwickler plagen bei der plattformunabhängigen Entwicklung viel weniger Sorgen als andere. Die virtuelle Maschine abstrahiert Betriebssystem und Hardware in hohem Maße, selbst für Details wie Byteorder oder Pfadangaben ist gesorgt. Trotzdem erspart dies dem Programmierer nicht, ausgiebig mit verschiedenen Plattformen zu testen. Das müssen nicht alle Java-Versionen auf allen Betriebssystemen sein, aber zumindest die vorletzte. Entwickler von GUI-Applikationen, die Swing als Basis benutzen, sollten zudem ihren Code mit den gängigen Look-and-Feels in Augenschein nehmen. (jk)