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.
guter Beitrag, aber was ist denn die glorreiche Alternative zu JSF, wenn das backend mit Java EE 6 entwickelt wird? Und warum ist jsf so schlecht geeignet?
SWT ist schon deutlich mächtiger als Swing – allerdings läuft es längst nicht so stabil. Und solange es nicht auf jeder gängigen JRE-Installation zuverlässig seinen dienst tut, ist das auch keine Lösung.
Es geht um Standards, und hier gibt es nur einen für Web-Entwickung, und das ist JSF. Wenn man alles nutzen darf, dann gibt es verdammt viele Alternativen: GWT, Vaadin, Stripes, Rails/Grails, … Aber darum geht es dem Forrester-Autor nicht. Er zeigt lediglich auf, was heute gefragt ist, und leitet ab, das Java SE/Java EE auf diese Anforderungen nicht vorbereitet ist.
JSF ist für einige Anwendungsfälle völlig in Ordnung. Der Autor die Folien greift sich jedoch einen ganz bestimmen Anwendungsfall heraus, der eher mit GWT/Silverlight/Flash gut abgedeckt ist, den Bereich der RIAs. Das ist mit JSF nicht sonderlich gut zu machen, da immer noch zu viel programmiert werden muss, statt deklarativ zu arbeiten.
Wer Java einfacher haben möchte, der sollte sich mal XDEV 3 ansehen. XDEV 3 ist eine Rapid Application Development IDE. Die Zeitschrift Java aktuell berichtet in ihrer aktuellen Ausgabe ausführlich über XDEV 3 http://www.ijug.eu/index.php?option=com_content&view=article&id=10&Itemid=35.
Mit XDEV 3 ist das Designen von Swing GUIs genauso einfach wie Grafikdesign. In wenigen Minuten lässt sich jede beliebige Oberfläche damit erstellen.
Neben dem GUI-Builder gibt es auch ein Databinding. Die ganze Arbeitsweise ist wie in Access und Visual Basic.
XDEV 3 ist völlig frei und steht unter http://www.xdev-software.de zum Download zur Verfügung.
Ich arbeite jetz seit einigen Wochen damit und ich bin absolut begeistert.
Im Moment ist das Projekt in einem fortgeschrittenen Betastadium, soll aber in 1-2 Monaten als final release verfügbar sein.
Danke für ihre Einsichten. 🙂
Ich bin gespannt bzw. hoffe das Oracle gerade im Bereich RCP mal ein wenig in die Gänge kommt.
Hallo !
Der Artikel ist mir zu kompliziert.
Doch meine Meinung sagen wollte ich mal.
JAVA kommt bei mir immer automatisch mit neuen Updates daher, soweit,so gut.
Ich ärgere mich jedoch regelmässig darüber, dass JAVA huckepack noch Programme mitbringt, mit denen ich nix anfangen kann und die dann nur Speicherplatz blockieren.
Muss das sein ? Ist übrigens nicht nur ein Problem von JAVA. Es passiert bei anderen
Programmen auch….nicht sehr schön, weil es mir den Spass verdirbt.
Irgendwann ist dann die Festplatte voll und dann geht gar nichts mehr.
Gruss Gast 59