Eröffnungspanel der W-JAX 2016

W-JAX 2016 eröffnet: Welches Java brauchen wir?

Hartmut Schlosser

Mit einem Panel zur Zukunft von Java hat Sebastian Meyen die W-JAX 2016 eröffnet. Unter dem Motto „Welches Java brauchen wir?“ diskutierten Arno Haase, Niko Köbler und Lars Röwekamp zu den Themen Java EE und Innovation in Java.

Gestartet ist die W-JAX vor 15 Jahren als Java-Konferenz, die die damaligen Hip-Themen Webservices und Wireless (das damalige „Mobile“) in das Programm integrierte (deshalb das „W“ im Namen). Seither ist die IT-Landschaft wesentlich komplexer geworden und von neuen Buzzwords wie Cloud, Container, Microservices, DevOps, Big Data/Fast Data, JavaScript umwölkt – Themen, an denen heute kein Java-Entwickler vorbei kommt und deshalb einen gewichtigen Teil des Programmes der W-JAX 2016 ausmachen.

Welche Rolle Java als Sprache und Plattform in diesem veränderten Kontext einnimmt, wurde in der Eröffnungskeynote am Dienstag Morgen von Sebastian Meyen, Arno Haase, Niko Köbler und Lars Röwekamp diskutiert.

W-JAX Panel

Eröffnungspanel der W-JAX 2016: v.l.n.r. Sebastian Meyen, Lars Röwekamp, Arno Haase, Niko Köbler

Wozu noch Java EE?

Ist ein großer Java Enterprise-Standard noch zeitgemäß? Brauchen wir angesichts der aktuellen Architekturdebatte über verteilte Microservices-Anwendungen überhaupt noch einen großen, standardisierten Architektur-Blueprint, der vorgibt, wie Java-Enterprise-Anwendungen zu bauen sind?

Für Lars Röwekamp ist Java EE zunächst einmal eine Sammlung von APIs, die Architekturvorschläge darstellen. Der Vorteil der Standardisierung liegt für Röwekamp darin, dass die Entwickler ein einheitliches, vertrautes Programmiermodell vor sich haben, mit dem Werte wie Zuverlässigkeit, Austauschbarkeit, Wiederverwendbarkeit verbunden sind. Sich in vielen Dingen nicht mehr um die technologischen Details kümmern zu müssen, schafft Raum, sich auf die wichtigen Teile einer Anwendung, nämlich auf die Fachlichkeit zu fokussieren.

Kritisch sieht Röwekamp die Verabsolutierung des Standards als verbindliches Ganzes. Schon immer sei Java EE als Ansammlung von Pattern gedacht gewesen, mit dem expliziten Hinweis, sich nur die jeweils nützlichen Teile herauszusuchen. Allerdings sei der Standardisierungsprozess über den JCP nicht mehr zeitgemäß, da Innovationen viel zu lange brauchen, um den Markt zu erreichen. Es fehle hier so etwas wie einen Lab-Modus, in dem Dinge mit der Community zusammen einfach und unkompliziert ausprobiert werden können.

In diesem Punkt des zu schwerfälligen Standardisierungsprozesses waren sich die Diskutanten durchaus einig. Etwas kritischer noch formulierte Arno Haase die Idee der Standardisierung über ein Gremium wie den JCP, da Innovationen nicht nur zu lange bräuchten, sondern immer auch eine Art Kompromiss darstellten. Da im Falle Java EE verschiedene Ansätze, Meinungen, Unternehmenspolitiken miteinander in Einklang gebracht werden müssen, sei das Ergebnis – die konkreten APIs – nur selten wirklich schön, rund, gut designt. Im Gegensatz zu Spring fehle Java EE zudem ein einheitliches Technologie-Rückgrat, das für Kohärenz sorgen würde. Viel Eigenarbeit sei deshalb nötig, und der Mut, große Teile der empfohlenen Standards wegzulassen, um wirklich gut designte, kohärente Anwendungen mit Java EE herzustellen.

Niko Köbler führte den Vergleich mit Spring fort und wünschte sich auch für Java EE eine ähnlich schnelle Time-to-Market-Spanne für Innovationen. Das Argument, Java EE profitiere von einem vertrauten Programmiermodell, wird laut Köbler dadurch abgeschwächt, dass die Einarbeitung in neue Libraries/Frameworks längst nicht mehr so schwierig sei wie früher. Junge, innovative Technologien behinderten also nicht die Konzentration auf die Fachlichkeit einer Anwendung sondern könnten sogar dabei behilflich sein, fachliche Anforderungen adäquater umzusetzen. Auch das Argument, dass man sich mit Spring im Gegensatz zu Java EE an einen einzigen Anbieter – VMware – binde, ließ Köbler nicht gelten. „Auch Java EE ist ein Vendor Lockin“, denn auch hier verlasse man sich auf ein Set von Technologien, die man nicht ohne weiteres einmal austauscht.

Java – die Sprache

Wie steht es nun aber um die Zukunft der Sprache Java? Hier riet Arno Haase dazu, die Programmiersprache gedanklich von der JVM zu trennen. Die JVM ist ein tolles Stück Code und eine der besten, wenn nicht die beste VM zurzeit. Haase: „Bei langlaufenden Anwendungen ist die JVM auch sicherlich kein Nachteil – und Anwendungen, die deployt und betrieben werden, werden nicht so schnell verschwinden.“

Betrachtet man indes die Programmiersprache Java, so attestiert Haase Java nur wenig Dynamik: „Java ist unter den großen Programmiersprachen die am wenigsten innovative“. Java sei gar ein Cobol 2.0 – was Haase gar nicht nur abwertend meinte, denn Werte wie Zuverlässigkeit, Langlebigkeit und Abwärtskompatibilität bescherten Cobol auch heute noch ein breites Anwendungsfeld. Doch Innovationen, so Haase, fänden heute in anderen JVM-Sprachen statt – was nicht unbedingt so sein müsste.

Lars Röwekamp berichtete hingegen aus seiner Praxis, dass viele Unternehmen selbst mit der bescheidenen Innovationsgeschwindigkeit, die Java an den Tag legt, nicht umgehen können. Häufig seien völlig veraltete Java-Versionen im Einsatz, und selbst deren „Innovationen“ würden nicht ausgenutzt. Deshalb sollte man sich die Frage stellen, wie man es schafft, diese Leute mitzunehmen.

Niko Köbler appelierte an Unternehmen, sich mehr mit den Neuerungen auseinanderzusetzen. Allerdings sei die Java-Community auch so konservativ „erzogen“ worden, da im Dienste der Rückwärtskompatibilität selbst jahrelang als „deprecated“ markierte Sprachelemente nicht entfernt wurden. Java könne hier durchaus von der JavaScript-Community lernen, die viel williger sei, Innovationen anzunehmen – und dazu auch gezwungen wird, da Breaking Changes weit weniger ein Tabu darstellen als in der Java-Welt.

„Vielleicht sollte Oracle auch mal altes Zeug rausschmeißen“, Unternehmen also quasi zur Innovation zwingen, kommentierte Köbler.

Welches Java wollen wir?

Am Schluss des Panels standen die Wunschvorstellungen der Panelisten, wie sich Java entwickeln sollte.

Lars Röwekamp: Wohldefinierte APIs, die sich weiterentwickeln, Erweiterung der Runtime z.B. durch Microprofile.io, Technologien-Probleme so lösen, dass man sich mehr Gedanken über Architektur und Fachlichkeit machen kann.

Arno Haase: Java sollte sich für Innovationen öffnen, anstatt Innovationen aktiv zu verhindern. Eine gesunde Sprache sollte es erlauben, Innovationen über Bibliotheken zu integrieren.

Niko Köbler: Wir brauchen keine Unterscheidung mehr zwischen Java SE und EE. Innovation sollte nicht in Standards sondern in einzelnen Projekten stattfinden. Und Oracle sollte mehr auf die Community hören, anstatt nur davon zu reden.

Mit diesen Schlussstatements entließ Sebastian Meyen das Publikum in die Konferenzwoche, in der wieder über 1000 Teilnehmer erwartet werden. JAXenter ist mit dabei und berichtet live vor Ort.

Stay tuned!

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: