Seite 3: Fazit

Inhaltsverzeichnis

Probleme der JVM-Sprachen

Die Einstiegshürde ist häufig ein politischer Aspekt, denn die Einführung neuer Sprachen ist sowohl gegenüber Kunden als auch Vorgesetzten zu "verkaufen". Letztlich ist die Angst vor einer neuen Sprache meist unbegründet, denn die Komplexität ist nicht höher zu bewerten als die Einführung eines WSDL-Compilers für SOAP-Webservices oder des GWT-Compilers zur JavaScript-Generierung inklusive der benötigten Konzepte. Deshalb sollte eine einzige weitere Bibliothek für ein Groovy-, Scala- oder anderes JAR auch keine Bedenken verursachen – es muss schließlich kein Code angepasst werden.

Neben dem politischen Aspekt besitzen moderne JVM-Sprachen aber auch einige konzeptionelle und technische Probleme, die nicht unerwähnt bleiben sollen. So ist die Plattformintegration ein wichtiges Thema und von Beginn an zu beachten. Zwar generiert jede JVM-Sprache Bytecode. Dieser ist jedoch nicht immer 100 Prozent kompatibel mit Java. Es sind nämlich alle in Java nicht vorgesehenen Sprachfeatures zu unterstützen. Beispielsweise sind Groovys Mixins, Scalas erweiterte Zugriffsrechte (wie private[this]) oder Clojures Makros sowie viele weitere Konstrukte in kompatiblen Bytecode zu übertragen. Umso problematischer wird es, wenn man nicht die Integration mit Java, sondern zwischen zwei anderen JVM-Sprachen benötigt. Daniel Spiewak erläutert beispielsweise, wie aufwendig die Kommunikation zwischen JRuby und Scala ist. Allerdings darf nicht unerwähnt bleiben, dass die Probleme bekannt sind und sich meistens durch einfache Workarounds lösen lassen. So wirkt ein Java-Interface als Schnittstelle oft Wunder.

Ein weiteres Problem ist, dass dank der zusätzlichen Sprachfunktionen gegenüber Java oftmals mit viel Mächtigkeit geworben wird, beispielsweise durch Meta-Programmierung oder implizite Typumwandlung. Allerdings kann dadurch schnell Code entstehen, der durch die mächtigen Sprachmittel kaum mehr verständlich zu lesen oder debuggen ist. Es gilt also, die Features einer Sprache gewissenhaft an den passenden Stellen einzusetzen. Ein sinnvoller Einsatz ist beispielsweise die Realisierung einer internen DSL. Wie komplex der innere Code ist, interessiert den Nutzer der DSL oftmals nicht.

Neben der Mächtigkeit ist außerdem zu beachten, dass die Entwickler die neuen Konzepte verstehen. So können viele Java-Entwickler mit unveränderlichen Objekten, Rekursion und Aktoren aus funktionaler Programmierung kaum etwas anfangen geschweige denn diese effizient einsetzen. Dynamische Sprachen bringen zusätzliche Probleme mit sich. Da im Quellcode keine Typen anzugeben sind und Fehler erst zur Laufzeit erkannt werden, ist der Quellcode schwerer lesbar und wartbar.

Hinzu kommt, dass die Unterstützung durch die gängigen Entwicklungsumgebungen zwar zunehmend besser wird, aber bei weitem noch nicht das Niveau von Java erreicht hat. Auch Tools zur Codeanalyse wie Sonar sind oft nicht kompatibel.

Fazit

Der Einsatz moderner JVM-Sprachen neben Java ist in vielen Situationen durchaus sinnvoll und schafft Mehrwert. Wichtig ist dabei, dass im neuen Projekt nicht vollständig umgestiegen werden soll oder muss, sondern diese Sprachen als gute Ergänzungen für die Java-Plattform zu sehen sind. Java bleibt in den nächsten Jahren die Kernsprache der Java-Plattform. Allerdings werden sich um Java herum weitere moderne JVM-Sprachen in konkreten Einsatzgebieten aufgrund ihrer Vorteile etablieren.

Wichtig ist, dass in einem Projekt unterschiedliche Konzepte verfügbar sind. So sollte das Entwicklerteam neben der Objektorientierung mit Java auch eine funktionale und eine dynamische Sprache in petto haben, um möglichst flexibel auf die Anforderungen reagieren zu können.

Für den Einstieg empfiehlt es sich, nicht auf die Referenzbücher zurückzugreifen, die alle Features der jeweiligen Sprache bis ins kleinste Detail erläutern. Besser geeignet sind Bücher wie "Making Groovy Java" oder "Grundkurs Funktionale Programmierung mit Scala", da diese ausgehend vom Wissen eines Java-Entwicklers auf die neue Sprache und deren neue Konzepte eingehen. Nach der Einarbeitung lassen sich die Sprachen zunächst in internen Projekten einsetzen, bevor sie später allein oder in Kombination mit Java an geeigneten Stellen auf die Kundenprojekte losgelassen werden.

Kai Wähner
ist als IT-Consultant bei der MaibornWolff et al GmbH tätig. Seine Schwerpunkte liegen in den Bereichen Java EE, SOA und Cloud Computing.

Literatur

• Kenneth A. Kousen; Making Java Groovy; Manning (Early Access Edition) 2011-12
• Lothar Piepmeyer; Grundkurs funktionale Programmierung mit Scala; Hanser, 2010
• Stefan Tilkov; Gelungene Mischung; Clojure: Ein pragmatisches Lisp für die JVM; Artikel auf heise Developer
• Stefan Kamphausen, Tim Oliver Kaiser; Moore in mind Parallelprogrammierung mit Clojure; Artikel auf heise Developer
• Heiko W. Rupp; Polyglotte Bohnen; Java-6-Scripting mit JRuby; Artikel auf heise Developer

(ane)