Java in der nächsten Dekade

Eberhard Wolff, Dierk König und Sebastian Meyen
Sinn und Unsinn der Standardisierung

Im Java-Umfeld gibt es etliche Standards, die genau so entstanden sind: Man hat sich verschiedene Technologie-Ansätze angesehen und vereinheitlicht. Dazu zählen zum Beispiel JDBC, Servlets, JMS oder auch JPA. Bei diesen Standards gibt es entweder ausreichende Erfahrungen mit den verschiedenen Implementierungen oder die Domäne ist gut genug verstanden, um einen Standard zu etablieren. Die Vorteile sind deutlich: So gewährleisten Servlets, dass viele Web-Frameworks ohne Probleme auf den verschiedenen Application Servern funktionieren. Mit JDBC ist die Integration beliebiger Datenbanken kein Problem.

Im ungünstigen Fall wird eine Standardisierung aber benutzt, um eine Technologie neu zu entwickeln oder gar proprietäre Technologien zu festigen, um sich gegenüber Wettbewerbern einen Vorteil zu verschaffen. Dieser Prozess lässt sich gut am EJB-Standard ablesen: dessen Kritiker bemängeln, dass das damals schon vorhandene Wissen über O/R-Mapper bei der Definition gar nicht genutzt wurde und es so bis zur dritten Iteration dauerte, eine sinnvolle Technik für die Persistenz in EJB zu integrieren.

Aufgrund der offensichtlichen Schwächen entstand damals (um die Jahre 2002-2004) mit JDO noch ein weiterer Standard für diesen Bereich – der wiederum mit EJB konkurrierte. Hätte man im Persistenz-Bereich die bekannten Ansätze beachtet, wäre die Standardisierung gewiss reibungsloser und für die Entwickler deutlich angenehmer verlaufen.

Kritiker weisen übrigens darauf hin, dass sich bei der aktuellen Debatte zur Modularisierung von Java ein ganz ähnlicher Prozess zu wiederholen scheint: Während mit OSGi ein langjährig bewährter Standard zum Thema vorliegt, arbeitet man mit Jigsaw an einem neuen Standard – bereits im zweiten Anlauf. Dass dies zu Frustration und Unverständnis in der Java-Gemeinde führen kann, liegt nahe.

Um diesen Problemen zu begegnen, werden in einigen klassischen Standardisierungs-Domänen wie dem JDK seit kurzem Open-Source-Projekte genutzt, um „mal eben etwas auszuprobieren“ und so Innovation zu erzeugen. Ein gutes Beispiel ist das Projekt Coin, in dem verschiedene Java-Sprach-Erweiterungen nicht nur diskutiert, sondern auch prototypisch implementiert worden sind, bevor sie in die Standardisierung eingeflossen sind.

Code First vs. Spec First

Das hohe Innovationstempo „da draußen“, welches es zukünftig der Java-Community nicht mehr erlauben wird, ein halbes Jahrzehnt an der Lösung eines technischen Problems zu werkeln, hat es mit sich gebracht, das zahlreiche Open Source-Projekte wesentlich erfolgreicher Neuerungen auf den Weg bringen als das JCP-Gremium. Mit Hibernate, Spring-Framework, Eclipse und vielen weiteren Technologien und Frameworks mehr hat die Java-Community demonstriert, zu welchen Innovationen sie fähig ist. Allen diesen Fällen ist gemeinsam, dass hier zuerst lauffähiger Code war und nur eventuell eine rückwirkende Standardisierung nachfolgte, wenn dies sinnvoll erschien. Auch JRuby oder Groovy entstanden jenseits des JCP und fanden nachträglich ihren Niederschlag in verschiedenen JSRs.

Darüber hinaus tendieren Standards dazu, das Falsche zu implementieren – zum Beispiel indem sie zu wenige oder zu viele Details oder nicht die relevanten Bereiche standardisieren. Dieses Problem ist allerdings nicht nur dem JCP zu eigen, sondern lässt sich z.B. auch an der OMG (Object Management Group) beobachten (der JCP kann in diesem Rahmen sogar als deutlich praxisrelevanter als viele andere Gremien bezeichnet werden).

Daraus folgt jedenfalls, dass die Rolle der Standardisierung im Lichte geänderter Herausforderungen sowie eines dramatisch gewachsenen Ökosystems nicht mehr die Rolle spielen kann, die sie einstmals spielte. Welche Aufgabe Standardisierung in der nächsten Dekade tatsächlich erfüllen kann, erscheint in diesem Zusammenhang noch nicht geklärt.

Das Java-Ökosystem

Der weltweite Siegeszug Javas und die Tatsache, dass geschätzte 9 Millionen Entwickler weltweit mit Java ihr Geld verdienen, hat es mit sich gebracht, dass die Rede von „der Java-Community“ überholt ist. Es ist schon seit langem keine einheitliche Community mit kohärenter Interessenlage und gemeinsamen Gegnern erkennbar – vielmehr haben wir es mit einer Vielzahl an Communities zu tun: Spring-Community, Eclipse-Community, Android-Community, Java EE Community, und wie man sie alle nennen mag.

Diese Differenzierung betrachten wir allerdings nicht als Problem, sondern als Stärke von Java. Denn war es in den Anfangstagen wichtig, zur Durchsetzung der Plattform mit einer Stimme zu sprechen, erlaubt der Erfolg von Java, dass vielfältige konkurrierende Vorschläge zur Verbesserung und Weiterentwicklung der Plattform vernehmbar sind.

Im Zentrum jeder Community steht dabei in der Regel entweder eine Technologie, um die sich Nutzer und Entwickler scharen, oder eine Organisation wie die ASF (Apache Software Foundation), die verschiedene Technologien entwickelt (und eine eigene Identität und Kultur entwickelt hat). Große und besonders aktive Zentren sind:

  • Apache Software Foundation (ASF)
  • Eclipse Foundation
  • Spring-Community/SpringSource
  • OSGi Alliance
  • JBoss
  • Google, JRuby, Scala, Closure & Co.

Neben diesen bekannten Communities gibt es noch viele weitere Projekte, die sich auf Portalen wie Sourceforge, Google Code oder GitHub sammeln und dabei Lösungen für fast jedes erdenkliche Problem anbieten. Diese unermessliche Vielfalt an zum großen Teil frei nutzbaren Technologien unterscheidet Java derzeit von allen anderen Plattformen.

Offene Innovation

Hinzu kommt eine große Anzahl klassischer Tool- und Technologieanbieter, die ebenfalls in beträchtlichem Maße und nicht nur über den „Umweg“ Open Source zur Weiterentwicklung Javas beitragen. Auch hier scheint bemerkenswert, dass es nicht nur die Großen sind, die mit nachhaltigen Innovationen glänzen, sondern mitunter auch sehr kleine, agile Firmen, die mit frischen Ideen in die Java-Arena stürmen. Zu letzteren könnte man zum Beispiel CloudBees, ZeroTurnaround oder auch Tasktop zählen, um nur einige wenige zu nennen.

Javas Innovationskraft entspringt wesentlich aus dem Java-Ökosystem – und das schon seit vielen Jahren! Gab es früher ein eindeutiges Gravitationszentrum der Java-Bewegung, sind es heute viele. Java ist ein multipolares Projekt, in dem verschiedene Akteure – große und kleine Unternehmen, Open Source-Projekte und Forschungseinrichtungen, Anwender und einzelne Aktivisten – für die notwendige Dynamik sorgen.

Das Java-Ökosystem lebt seit mehreren Jahren erfolgreich vor, wie ein Open Innovation-Prozess aussehen kann!

Zusammenfassung

Java ist die Plattform mit der weltweit größten Verbreitung, und es ist dabei weit mehr als „nur“ eine Programmiersprache (für das es von vielen immer noch gehalten wird). Java ist eine äußerst robuste Plattform, die sich seit mehr als einem Jahrzehnt in Unternehmensanwendungen verschiedenster Art bewährt. Darüber hinaus hat sich Java nicht zuletzt in den letzten Jahren als äußerst innovationsfreudig gezeigt, wenngleich die Ablösung von Java 6 erheblich länger dauert als ursprünglich geplant.

Diese Stagnation ist zwar ein echtes Problem, betrifft allerdings nur den Java-Kern, und nicht das Ökosystem. Letzteres generiert mit hoher Regelmäßigkeit jede Menge Technologien, Tools, Frameworks und Projekte. Das Ökosystem ist heute lebendig wie nie zuvor!

Ausblick

Die Artikelserie „Java der nächsten Dekade“ wird die beschriebenen Änderungen in der IT-Welt aufgreifen und dabei untersuchen, welche Antworten das Java-Ökosystem auf die aktuellen Herausforderungen parat hat. Sie soll zu einer offenen Diskussion einladen sowie Orientierung bieten, damit sich der Leser – als Entwickler, Architekt, Analyst oder Manager – frühzeitig auf die wichtigsten Trends einstellen kann, um so gut für die Zukunft vorbereitet zu sein.

Das Kuratorium der Serie will nicht die Zukunft vorhersagen, sondern konzentriert sich darauf, verschiedene relevante Standpunkte darzustellen. Dazu werden wir verschiedene Autoren einladen, über ihr Spezialgebiet zu berichten, wir werden Interviews mit Vordenkern der Java-Szene präsentieren oder auch kontroverse Standpunkte darstellen. Die einzelnen Folgen der Serie werden zum Teil im Java Magazin erscheinen und können auf JAXenter diskutiert werden. Wir freuen uns über Ihre Rückmeldungen und treten gerne in Dialog mit Ihnen.

Eberhard Wolff (Twitter: @ewolff) arbeitet als Architecture & Technology Manager für die adesso AG. Seine Schwerpunkte liegen auf Cloud-Technologien, Enterprise Java u.a. mit Spring und Software-Architekturen.

Dierk König (Twitter: @mittie) ist Fellow bei der Canoo Engineering AG in Basel. Er betreibt das Open-Source-Projekt Canoo WebTest und ist Committer in den Projekten Groovy, Grails und GPars. Er publiziert und spricht auf internationalen Konferenzen zu Themen moderner Softwareentwicklung. Er ist Autor des Buchs „Groovy in Action“.

Sebastian Meyen (Twitter: @smeyen) ist Chefredakteur des Java Magazins sowie des Eclipse Magazins. Außerdem trägt er die Verantwortung für Programm und Konzept sämtlicher JAX-Konferenzen weltweit. Er begleitet so die Java-Community journalistisch schon fast seit ihren Anfängen. Bevor er zur Software & Support Media GmbH kam, studierte er Philosophie in Frankfurt.

Bernd Kolb is working as an architect for SAP AG in Walldorf. His main areas of work are OSGi, various Eclipse technologies and Modeling. Before Bernd joined SAP, he was working as an independent consultant in different domains from tooling for automotive embedded systems to enterprise Java applications.

Geschrieben von
Eberhard Wolff, Dierk König und Sebastian Meyen
Kommentare

Schreibe einen Kommentar

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