Suche

Java ist nicht schlecht – Ihr benutzt es nur falsch!

Michael Thomas
© Shutterstock.com/ScandinavianStock

Java Doesn’t Suck – You’re Just Using it Wrong„. Von diesem Standpunkt ist zumindest James Ward (Principal Platform Evangelist bei Salesforce.com) überzeugt. Der Grund für den schlechten Ruf der Java-Plattform in manchen Kreisen liegt seiner Meinung nach darin, dass viele Java-Entwickler weiterhin Konzepten und Vorgehensweisen anhängen, die durch die Weiterentwicklung des Java-Ökosystems eigentlich bereits überwunden sind.

Insgesamt nennt Ward 10 der schlimmsten Java-Sünden, die ihm während seiner Berufslaufbahn persönlich begegnet sind – und stellt mögliche Alternativen vor.

1. Umständliches Einrichten von Entwicklungsumgebungen

Das Einrichten einer Entwicklungsumgebung sollte Ward zufolge maximal 3 Schritte umfassen: Installation des JDK, Klonen des SCM Repo und Starten des Builds/der App. Moderne Build-Tools wie Gradle können dies leisten. Besonders Container-lose Lösungen wie das Play Framework und Drop Wizard bieten entsprechende Komplettpakete. Intelligente Build-Systeme nehmen es einem Entwickler zudem ab, Service-Abhängigkeiten wie Datenbanken und externe Web-Services einzurichten und zu konfigurieren bzw. die dazu notwendigen Dienste lokal oder über die Cloud bereitzustellen. Sollte die eigene Anwendung eine relationale Datenbank benötigen, empfiehlt Ward eine In-Memory-Datenbank wie sql oder Cloud-Dienste wie Heroku Postgres, RDS oder Redis Labs.

2. Inkongruente Bereitstellungsumgebungen

Das einzige, das Ward zufolge zwischen jeder Umgebung wechseln sollte, ist die Konfiguration. Auf kontinuierlicher Integration aufbauende Systeme sollte die selben Builds und Tests wie Entwickler laufen lassen sowie Test- und Staging-Umgebungen automatisch bereitstellen.

3. Server, die mehr als 30 Sekunden für den Start benötigen

Braucht ein Server länger als 30 Sekunden für den Start, sollte man Ward zufolge über die Übernahme einer Microservives-Architektur nachdenken. Containerlose oder „Nur eine App pro Container“-Lösungen können die Anlaufzeit signifikant reduzieren.

4. Manuell gemanagte Abhängigkeiten

Bibliotheksabhängigkeiten sollten heutzutage nicht mehr händisch gepflegt werden, stattdessen bietet sich die Nutzung von Build Tools wie Ant + Ivy, Maven, Gradle oder sbt an.

5. Unversionierte und unveröffentlichte Bibliotheken

Die innerhalb eines Unternehmens genutzten Bilbiotheken sollten versioniert und auf internen Artefaktservern wie Nexus und Artifactory veröffentlicht werden. Um reproduzierbare Builds zu erhalten, sollte bei der Versionierung auf die SCM-Informationen zurückgegriffen werden. Das Plug-in sbt-git beispielsweise korreliert die Build-Version mit dem git-Hash.

6. Lange Entwicklungs- und Validierungszyklen

Moderne Webframeworks wie das Play Framework und Tools wie JRebel können von Entwicklern dazu genutzt werden, Codeänderungen schneller zu sehen und (kontinuierlich) zu testen. Der Test einer Codeänderung sollte nicht mehr Zeit ein Anspruch nehmen als die inkrementelle Kompilierung. Die Nutzung von Webframeworks, welche Kompilierungs- und Runtime-Fehler nach einem Browser-Refresh anzeigen, bietet sich ebenfalls an.

7. Monolithische Releases

Monolithische Releases bergen ein nicht unerhebliches Risiko: Treten Probleme auf, kann mitunter die Arbeit von Monaten vernichtet werden. Deshalb bietet es sich an, die Release-Zyklen auf einen zweiwöchigen Rhythmus einzustellen. Continuous Delivery reduziert nicht nur das kumulative Risiko von Releases, sondern weckt auch regelmäßig das Gefühl, etwas geschafft zu haben (Stichwort „positive Selbstbestärkung“).

8. Sticky Sessions und Server State

Sticky Sessions und Server State können wahre Performance-Fresser und Resilienz-Killer sein. Session State erschwert die Continuous Delivery sowie die horizontale Skalierung. Wenn man Session-Cache haben möchte, sollte man auf echte Cache-Systeme wie etwa Memcache oder ehcache zurückgreifen. UI-bezogener State sollte auf dem Client (z.B. Cookies, In-Memory) oder in externen Datenspeichern (z.B. SQL/NoSQL-Datenbanken, verteilte Cache-Cluster) zu Hause sein. REST-Services schließlich sollten immer zu 100% ohne State auskommen.

9. Sinnloses Blockieren

Die meisten traditionellen Java Networking-Bibliotheken wie Servlets, JDBC oder Apache HTTP sind blockierend, was bedeutet, dass selbst einer Verbindung im Leerlauf ein Thread zugeordnet wird. Dieses Modell limitiert u.a. die horizontale Skalierbarkeit. Das reaktive Modell hingegen setzt nur dann Threads ein, wenn auch tatsächlich etwas passiert, weshalb die eigene App idealerweise bis in die grundlegenden Network-Events hinein reaktiv sein sollte. Zu diesem Zweck stehen mittlerweile zahlreiche reaktive Bibliotheken und Frameworks bereit, die auf NIO und Netty aufbauen.

10. Java als Sprache

Gerade weil Java von vielen Unternehmen eingesetzt wird, die Konsistenz wünschen, hat Java als Sprache überwiegend graduelle Änderungen erfahren und ist deshalb etwas in die Jahre gekommen. Ward empfiehlt daher, über den Einsatz alternativer Sprachen in der JVM – darunter Scala, Groovy, Clojure und Kotlin – nachzudenken, da diese jeweils spezifische Vorteile bieten. Dank entsprechender Frameworks und Build-Tools können diese auch für bereits bestehende Projekte verwendet werden. Auch die Nutzung der Java 8-Lambdas bietet sich an, da diese gut mit dem reaktiven Modell harmonieren.

Aufmacherbild: Java concept blue background with blue text von Shutterstock / Urheberrecht: ScandinavianStock

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare
  1. jhunovis2014-12-18 06:30:02

    Nette Zusammenfassung. Bitte auch den Link auf den Original-Artikel mit angeben:

    http://www.jamesward.com/2014/12/03/java-doesnt-suck-youre-just-using-it...

  2. Joachim2014-12-22 12:09:19

    hallo und moin

    Java 8 kann ich die Sicherheitseinstellungen nicht machen. und die beschreibungen bei Java 8 kann ich nicht nachvollziehen, es wird nirgens beschreiben was machhen machen muß. ! Bitte um hilfe.

    MFG
    Joachim bengen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.