Java in der nächsten Dekade

Eberhard Wolff, Dierk König, Sebastian Meyen und Bernd Kolb

Das Jahr 2010 wird als tiefe Zäsur in die Entwicklung Javas eingehen. Durch die Übernahme von Sun durch Oracle haben sich die Machtverhältnisse nach rund 15 Jahren deutlich verschoben. Zugleich ergibt sich ein verändertes Bild, was die Anforderungen an zeitgemäße IT-Systeme betrifft. Damit stellt sich die Frage, wer nun über die Geschicke Javas bestimmen darf; welche Prioritäten werden gesetzt? Wie sollte sich Java weiter entwickeln, um auch in der nächsten Dekade seine Position im Wettbewerb der Plattformen auszubauen? Das Java-Ökosystem – die Ganzheit aller Akteure im Java-Bereich – liefert interessante Antworten.

Eine Branche im Umbruch

Es scheint, dass eine erhebliche Bewegung in unsere Branche gekommen ist. Lange Zeit war das Java-Programmiermodell insbesondere in Europa unangefochten, wenn es um Business-Applikationen mit starker Webanbindung ging. Jetzt aber tauchen gleich mehrere neue Anforderungen am Horizont auf, die die Art und Weise, wie wir Systeme für unsere Kunden bauen, nachhaltig verändern werden.

Neue technische oder fachliche Herausforderungen ergeben sich nicht plötzlich und unerwartet, sie sind, vielmehr Resultate lange währender Prozesse. Trotzdem lassen sich immer wieder gewisse „Zeitenwenden“ erkennen, von denen wir eine, nämlich die an der Schwelle des neuen Jahrzehnts, im Folgenden näher beleuchten wollen.

Wir, das Autorenteam, sind uns dabei bewusst, dass wir allenfalls nur Schlaglichter auf das Geflecht an Trends werfen können, die da gerade unsere Branche verändern. Wir glauben aber, dass es sich lohnt, sie in einen Zusammenhang mit Java zu stellen und darüber nachzudenken, welche Antworten das Java-Lager denn auf diese veränderte Lage zu bieten hat.

Wir verstehen unseren Beitrag ausdrücklich als Vorschlag für eine Diskussion und nicht als abgeschlossene Analyse. Folgerichtig wollen wir hiermit eine Serie von Beiträgen starten, die sich alle mit verschiedenen ausgewählten Aspekten von Java, wie es in der nächsten Dekade aussehen wird oder aussehen sollte, beschäftigen. Es wird dabei polemische Beiträge geben und streng analytische, Interviews, Hintergrundberichte und auch Kontroversen. Wir verstehen das „Java der nächsten Dekade“ – so der Titel der Serie – als lebendiges Forum für Inspiration, Austausch und Information.

Deshalb ist uns vor allem eins wichtig: Ihr Feedback!

  • Kommentieren Sie bitte diesen Artikel.
  • Twittern Sie darüber mit dem Hashtag #JaxJavaPanel.
  • Oder – wenn es detaillierter wird – bringen Sie Ihre Meinung zu Papier und schicken diese an redaktion[at]javamagazin.de. Wir als Autoren-Team prüfen alle Beiträge und veröffentlichen sie ggf. innerhalb dieser Serie!

Sie können auch live mitdiskutieren: nächste Woche auf der JAX in Mainz findet ein Panel zu „Java in der nächsten Dekade“ statt (Donnerstag, 15:30 Uhr). Wir freuen uns auf Sie!

Neue Herausforderungen

Der PC und das Client/Server-Modell löste seinerzeit den Mainframe ab als vorherrschendes Paradigma ab, das Web dann das Client/Server-Modell, Sie kennen die ganze Geschichte. Was wir uns dabei klar machen müssen, ist dass wir uns gegenwärtig wieder an der Schwelle zu solch einer tiefgreifenden Transformation befinden. Gewiss, das Web als zentrales Medium bleibt erhalten und zahlreiche Techniken, die wir anwenden, werden noch lange Bestand haben, aber es gibt auch eine Fülle alter Gewohnheiten, die wir in Frage stellen müssen.

Betrachten wir die wichtigsten Faktoren Schritt für Schritt:

Mobile: Die immer größere Verbreitung von mobilen Endgeräten, ausgelöst durch die Smartphones von iPhone bis Android sowie der neue Markt der Tablets birgt neue Herausforderungen. Hinzu kommen mobile und eingebettete Systeme in Fahrzeugen, Fahrkartenschaltern, Verkaufsterminals oder Fernsehgeräten, die alle Metapher von der gewohnten Desktop-basierten Webanwendung obsolet machen. Apps auf verschiedenen Plattformen, mit variierender Bildschirmgröße und unterschiedlichen Interaktionsmodellen sind die künftigen Clients unserer im Web gehosteten Dienste. Hinzu kommen Browser-Anwendungen und Web-Widgets für unterschiedliche Geräte und Use Cases. Die Fülle unterschiedlicher Systeme, die zukünftig Clients unserer Dienste sein werde, ist schier unüberschaubar. Dies stellt auch den Backend-Entwickler vor neue Herausforderungen.

Auch App-seitig, also auf der Seite der neuen Clients, warten vielfältige Aufgaben. Nicht nur, dass Java ME bei allem Erfolg auf den so genannten Feature Phones auf den Smartphones – den Geräten, denen die Zukunft gehört – praktisch keine Rolle spielt, muss man sich in Android, Apple iOS, Blackberry und in Mobile Web-Technologien (viel JavaScript!) einarbeiten bzw. hauseigene Kompetenzen aufbauen.

Cloud: Spätestens seit sich herumgesprochen hat, dass man bei Amazon nicht nur Bücher und Weihnachtsgeschenke kaufen, sondern auch Rechenpower und Speicherplatz mieten kann, beginnt sich auch die Entwicklung und der Betrieb von Software zu ändern. Wo früher CDs gepresst, verschickt und beim Anwender installiert wurden, werden immer häufiger Software as a Service (SaaS)-Lösungen angeboten.

Die Cloud wird aber nicht nur ein moderneres Hosting für konventionelle, monolithische Java-Server repräsentieren, sondern die Art und Weise, wie wir Lösungen konstruieren, deutlich verändern. Es wird sehr einfach, neue virtuelle Rechner oder mehr Storage in eine bestehende Anwendung zu integrieren. Man muss aber mit weltweit verteilten Rechnern und Rechenzentren umgehen, in die Anwendungen deployt werden und Daten
bereitgestellt werden müssen. Und obwohl die Infrastruktur nicht unter der eigenen Kontrolle steht, muss die gebotene Zuverlässigkeit (Service Level Agreements) erreicht werden. Das wird ganz andere Architekturen und Programmierkonzepte erfordern, die in Zukunft mit der Java-Plattform realisiert werden.

Alles in handelt es um ein fundamental neues Betriebskonzept, das Themen wie Elastische Skalierung auf die Tagesordnung bringt und ein neues Verhältnis zwischen Entwicklung und Operations definieren wird (siehe auch den Abschnitt „DevOps“ weiter unten).

NoSQL: Die Menge anfallender Daten ist heute schon enorm und wird sich noch drastisch erhöhen – unser Bedürfnis, komplexe Vorgänge zu messen und verstehen um daraus Rückschlüsse fürs Geschäft ziehen zu können, erfordert immer mehr Datenerhebung. Allein das Wissen, welche Nutzer zu welchem Zeitpunkt welche Dienste zu welchem Zweck und wie benutzen, kann in Zukunft über den Erfolg eines Produkts oder gar eines ganzen Unternehmens entscheiden. Herkömmliche Relationale Datenbanken können da schnell an ihre Grenzen gelangen.
Weitere Gründe für NoSQL sind auch alle Bereiche, die unter den Begriff „Connected Data“ fallen – also viele Formen von Blogs, User Generated Content, semi-strukturierte Daten, die nicht in herkömmliche Relationale Datenbanken „passen“.
Nicht zuletzt aus dieser Erkenntnis heraus sind verschiedene NoSQL-Stores entstanden, welche zum Teil bereits ihre Produktreife demonstriert haben. Dabei sollte beachtet werden, dass die Bezeichnung „NoSQL“ nicht auf eine Verneinung der Abfragesprache SQL hinausläuft, sondern von vielen Vertretern der Szene als „Not only SQL“ paraphrasiert wird.

Prominente Anwender dieser Datenspeicher sind z.B. Facebook, Twitter oder Google, deren Angebote naturgemäß auf der Auswertung extrem großer Datenmengen bei exorbitant hohen Nutzerzahlen beruhen.

Dabei ist wichtig, dass künftig eine Vielzahl an Branchen, nicht nur die ganz Großen im Web, auf den Umgang mit Massendaten vorbereitet sein müssen. Finanzbranche, Energiewirtschaft, Logistik, Handel sind nur ein paar Vertreter, deren Bedarf an immer komplexerer Datenauswertung in Nahezu-Echtzeit spontan einleuchtet.

Ist die Java-Community mit ihrem beinahe zehn Jahre währenden Ringen um die beste Lösung für einen transparenten Datenbankzugriff, auf diese Entwicklung vorbereitet?

Web: Zugleich ist die Internet-Revolution bereits in die nächste Runde gegangen. Klassische Webanwendungen, wie wir insbesondere in der Java-Welt sie seit den späten 1990ern kennen, stellen noch monolithische Endpunkte dar in einem Web, dessen Verflechtungsgrad aber kontinuierlich zunimmt. Zukünftig werden verstärkt Internet-Technologien wie HTTP, JSON, REST, XML, OAuth und mehr für das Deployment von Anwendungen genutzt werden. Dabei geht es sowohl um den Client (mobil, eingebettet oder klassischer Desktop) als auch den Server, die Kommunikation zwischen Client und Server sowie auch die Integration von Systemen oder Diensten. Das Web wird sich dabei auch zunehmend zu einer Integrationsplattform wandeln.

DevOps: Bei den Methoden für die Softwareentwicklung hat sich das agile Gedankengut mittlerweile im Mainstream verbreitet – wenn auch nicht überall praktisch im Einsatz, haben die agilen Methoden längst ihren Exotenstatus überwunden und gelten als eine der besten Möglichkeiten, produktiv Software mit hoher Qualität zu entwickeln. Allerdings wurden Deployment und Betrieb bislang außen vor gelassen.
In einem Geschäftsumfeld, in dem Änderungen an bestehenden Systemen in immer kürzeren Zyklen gefordert werden, wird ein höheres Maß an Flexibilität auf Seiten der Technik erforderlich. Und nicht zuletzt durch den Einfluss des Cloud Computings, das Deployment und Betrieb ohnehin tiefgreifend verändert, müssen neue Wege gesucht werden, um Entwicklung und Betrieb enger miteinander zu verzahnen.

Dieses Ziel hat sich die DevOps-Bewegung auf die Fahnen geschrieben. So kann der Betrieb z.B. Monitoring-Werkzeuge anbieten, die für die Entwicklung wertvolles Feedback geben können. Dazu muss die Entwicklung entsprechende Schnittstellen implementieren, welche die dafür relevanten Daten liefern. Gleichzeitig wird durch DevOps die Automatisierung von Deployment-Prozessen angestrebt, um so den Schritt in die Produktion so einfach wie möglich zu machen. Dies wieder bedeutet, dass Entwickler ohne Einbeziehung der Admins, Features in Produktion bringen können, was wiederum die Verantwortung für Features und eventuelle Produktionsprobleme in Richtung der Entwickler verschiebt.

Durch die unter dem Schlagwort „DevOps“ versammelten Ansätze wird die gesamte IT flexibler und Entwicklungsteams müssen sich mit den geänderten Verantwortlichkeiten und Ansprüchen auseinander setzen.

Programmiersprachen: Nach einer relativ langen Phase der Stagnation haben sich in den letzten Jahren mehrere ernsthafte Sprachen für die Java-Plattform herausgebildet. Gegen den Alleinvertretungsanspruch von Java (der Sprache!) sind Groovy, JRuby, Scala, Clojure & Co. angetreten, um Java (die Plattform!) zu bereichern. Dynamische Sprachen wie Groovy, JRuby oder JavaScript erhalten eine zunehmende Bedeutung, während auf der anderen Seite mit Scala eine Sprache an Popularität gewinnt, die ein mächtiges Typsystem bietet.

Scala ist mit seiner hybriden Natur nicht nur objektorientiert, sondern auch ein Vertreter funktionaler Sprachen. Dieser Sprachtypus hat lange ein Nischendasein geführt, wird aber durch die Vorteile, insbesondere bei nebenläufiger Programmierung, wieder in Erwägung gezogen. Sogar eine vorwiegend funktionale Sprache wie Clojure bekommt in diesem Zusammenhang eine gewisse Aufmerksamkeit. Auch eigene Sprachen, so genannte Domain Specific Languages (DSLs) werden immer mehr hoffähig. Entweder eingebettet in eine Hostsprache wie beispielsweise JRuby (on Rails) oder Groovy (Grails), aber auch als Ergebnis von Code-Generierung haben sie bereits heute ihre Bedeutung.

Für den Java-Entwickler bedeutet dies den Abschied von dem Prinzip „Eine Plattform – eine Sprache“. Eher wird man sich daran gewöhnen müssen, dass es mehr als eine Sprache gibt.

Multicore: Dass die Weiterentwicklung herkömmlicher Prozessoren an ihre Grenzen gelangt und man darauf ausgewichen ist, mehrere Prozessorkerne zur Leistungssteigerung auf einer CPU zu platzieren, scheint schon im allgemeinen Bewusstsein angekommen zu sein. Man bedenke, selbst das neue iPad 2 läuft mittlerweile auf 2 Kernen, und viele weitere Geräte werden folgen. Welche Auswirkungen dies für Softwareentwickler hat, scheint in der Theorie hinlänglich bekannt, in der Praxis allerdings aktuell noch irrelevant zu sein. Nur so lässt sich der nachlässige Umgang mit dem Thema, aber auch der Mangel geeigneter Technologien, erklären. Um dieser großen Herausforderung zu begegnen, gibt es verschiedene Ansätze – wahlweise auf der Sprachebene, in Frameworks oder Libraries. Welche davon sich durchsetzen werden, ist aktuell nur schwer abzusehen.

Geschichte des JCP

In der Anfangszeit war die Java-Community der wesentliche Technologietreiber. Die Allianz rund um Sun definierte Standards, Technologien, Werkzeuge mit denen die „E-Business“-Revolution offensiv vorangetrieben werden konnte. Vertreter anderer Technologien hatten das Nachsehen und mussten oft nachziehen. Mittlerweile hat sich das Blatt allerdings gewendet – wesentliche Innovationsschübe kommen den verschiedensten Parteien – innerhalb oder außerhalb des Java-Ökosystems. Es gilt für das Java-Volk daher, adäquate Antworten auf die Herausforderungen zu entwickeln.

Aus den Anfangstagen Javas, als die Java-Allianz nicht zuletzt als Gegenentwurf zu Microsofts proprietären Technologien startete stammt die tiefe Überzeugung, dass Technologien standardisiert werden sollten, um langfristig Bestand zu haben und um nicht fragmentiert oder verfälscht zu werden. So nahm der Java Community Process (JCP) bald eine dominierende Rolle ein bei der Definition, aber auch bei der Weiterentwicklung von Java.

Das Prinzip des JCP funktionierte auch zu aller Zufriedenheit zu einer Zeit, als es darum ging, verschiedene konkurrierende Ansätze zu vereinheitlichen, wenn die Unterschiede nur noch marginal sind und die Technologien gut verstanden. Ganz nach dem Beispiel von Schraubengewinden: Warum zahlreiche unterschiedliche Gewinde auf den Markt werfen, wenn doch alle Akteure davon profitieren, wenn es nur einige wenige gibt.

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

Schreibe einen Kommentar

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