Nach dem Eintrag im Blog (http://www.tutego.de/blog/javainsel/2011/02/forrester-untersuchung-sagt-java-taugt-nix-fr-enterprise/) über die Forrster Studie fragte ein Kommentator nach meiner Einschätzung. Also, taucht Java ab oder taugt es?

Es ist schwer einen Anfang zu finden, denn verschiedene Sachen laufen immer durcheinander. Zunächst ist Java eine Vereinigung:

Java = JVM + Java als Programmiersprache + Java SE Lib + Java EE Lib (wenn man Enterprise hinzunehmen möchte)

Man könnte noch “Great Communitiy” oder große Anzahl Open-Source Libs dazu nehmen, aber darauf kommt es jetzt nicht an.

An den Gliedern kann man anfangen unter verschiedenen Bewertungskriterien rumzunörgeln. Es steht außer Frage das die JVM unglaublich leistungsfähig ist. Bei der Programmiersprache Java fängt aber die Kritik schon an – bei der Java SE geht es weiter. Java EE kann man auch kritisieren, jedoch für einen anderen Grund.

• Die Sprache Java hat sich die letzten Jahre nicht gewandelt, aber Skriptsprachen zeigen zum Beispiel deutlich den Trend auf, Collection-Unterstützung in den Sprachkern aufzunehmen und Closures sowie funktionale Aspekte zu unterstützen desweiteren Nebenläufig besser anzugehen.
• Die Bibliotheken haben deutliches Potenzial. Einmal horizontal (unterschiedlichen Technologien) wie vertikal (in der Tiefe). Wenn Java SE schon fertig wäre, wäre Apache Commons * oder Google Collections/Guava gar nicht nötig. Wenn Java EE auch den Web-Technologie-Teil abdecken soll, OOOHA, da ist noch viel zu tun.

Der Autor der Studie ist nicht gegen Java: die Folien zeigen, das Java in vielen Bereichen perfekt passt. Er macht aber klar, dass Java eben nicht für jedes Problem die Antwort ist. Da hat der Mann natürlich Recht! Mit der Banane einen Nagel in die Wand zu schlagen wird auch kompliziert. Java ist explizit als General Purpose Sprache entworfen worden. Das heißt: Für alles und nichts! Während man außer Frage stellt, Java im Bereich Treiberprogrammierung einzusetzen, versuchen viele Java (also die Sprache + Java SE + Java EE) dort einzubringen, wo es bessere Lösungen gibt. Java ist im Gui-Bereich einfach schwach. Punkt. Gui ohne Databinding? Nicht gut. (Es geht immer noch darum, dass es kein Teil der Standard-Bibliotheken ist. Natürlich gibt es Databinding am Open-Source-Himmel … sogar gaaaanz viele Lösungen.) Es steht außer Frage, dass man mit Swing und JSF absolut geile Lösungen bauen kann. Doch Softwareentwicklung besteht nicht daraus, mit ein paar Experten ein System zu bauen; gibt Experten FORTRAN oder COBOL und auch dann wird das Design super sein.

Die zentralen Schwachpunkte im Gui-Bereich sind:

• Zu kompliziert mit den STANDARD-Frameworks für den Durchschnitts-Joe. In einer Tabelle eine Fließkommazahl mit zwei Nachkommastellen zu formatieren muss einfacher gehen als extra einen Cell-Renderer zu programmieren.
• Für echte Oberflächen muss man zukaufen, OS-Libs nehmen, oder stark in Eigenentwicklung investieren. Databinding gibt es, klar, aber eben nicht im Java SE. Man schaue nur auf Eclipse RCP und dann sieht man, was in Swing alles fehlt.
• Agil mal eben schnell eine Änderungen umzusetzen geht nicht.

WENN man also Gui-Entwicklung zur Enterprise-Entwicklung zählt – und das tut der Autor der Studie, das ist aber auch Diskussionssache – hat er mit seiner Kritik recht. Mich wundert, was es an dem Punkt zu diskutieren gibt. Die Diskussion gleitet schnell in die Richtung das man sagt: Ja, aber in Ruby, mit Eclipse RCP, mit Vaadin, mit bla, … geht das alles! Stimmt, es geht aber hier um pures Java und um das, was in Java SE/Java EE von Oracle kommt. Hier hat eben Java nichts zu bieten. Ich finde Swing toll und mag es, aber für heutige Richclient-Anwendungen ist das nichts. Auch JSF ist nichts für moderne RIA-Anwendungen. Viel zu HTML-lasting.

Java EE ist im Kern ausgereift und für Geschäftslogik und Persistierung nahezu perfekt. Container wie GlassFish machen es rund. Hier liegt nicht das Problem. Entwickler großer Anwendungen müssen lernen das richtige Tool für den Job zu finden. Im Enterprise Bereich ist Java EE 6 ein guter Anfang für das Backend. Den Gui-Bereich können wir aufgeben. Klar, das es mit Swing und JSF “irgendwie geht”, aber wie gesagt: es darf keine Technologie für Experten sein. Es wird natürlich immer Softwareentwickler geben die sich wünschen, das eine Technologie für Experten ist, aber es geht um Wirtschaftlichkeit, ob wir das wollen oder nicht. Und wenn eben ein Swing-Entwickler für einen neuen Button 20 Minuten im Quellcode braucht, der Silverlight-Entwickler aber nur 5 Minuten, ist klar, wie die Rechnung aussieht. Und selbst das ist noch viel zu low-level gedacht.

Selbst wenn man Java aufbohrt und pimpt bis zum Abwinken mit Business-Rules-Engine, alles in dynamischen Programmiersprachen auf der JVM entwickelt, usw. usw., es wird immer noch zu viel selbst gebaut. Entwickler müssen lernen, sich in komplexe existierende Systeme einzuarbeiten, und auf deren Basis eigene Lösungen entwickeln. Im Web-Bereich sei einmal der JBoss-Stack oder Alfresco in den Raum geworfen, aber auch richtig fette Sachen wie SAP, auch wenn vielen das nicht gefallen dürfte. Oder Talend zur Konvertierung. Der Autor der Studie lässt Alternativen vielleicht bewusst offen (RoR wird genannt im Web-Bereich) und ich vermute einfach deswegen weil es keine Alternativen gibt! Oracle bietet eine wunderbare Basis aber es liegt an uns, mächtigere Framworks, und dann auch DSL für spezifische Probleme zu nutzen. Java hat seinen Platz und ist eben nicht für alles zu gebrauchen. Ich erinnere mich gut an dBASE, das zeigt schon vor über 10 Jahren die Richtung auf: Eine Entwicklungsumgebung mit Programmiersprache. Das ist Rapid Application Development von datatenbankgetriebenen Anwendungen. Eigenentwicklung wird es immer geben, aber für gewisse Probleme funktionieren wunderbar 4GL-Lösungen.

Ähnliche Beiträge

• Meine Freundinnen
• Kann Apache ein Java alleine stemmen? Gedanken zur Festzeit
• NetBeans 7.3 final und aus der Beta-Phase
• PDFs in/mit/aus Java erstellen, ein leidiges Thema
• DZone-Interview mit Sacha Labourey über JBoss AS 5