JSP, JSF, Vaadin, Struts, Spring MVC, Wicket werden verschwinden – die Zukunft: OSGi & HTML5

Hartmut Schlosser

Die meisten Java Web Frameworks wie JSP, JSF, Vaadin, Struts, Spring MVC oder Wicket werden im Laufe des nächsten Jahrzehnts der „Mülltonne der Geschichte“ überantwortet werden. Mit dieser provokanten Aussage leistet OSGi-Gründer Peter Kriens einen Beitrag zur Diskussion um die Zukunft der Webentwicklung. Die Zeiten, als Java-Entwickler noch Rebellen waren, sind vorbei, sagt Kriens. Jetzt ist es an einer anderen Technologie, die Rolle des Erneuerer zu übernehmen, und diese Technologie heißt HTML5.

HTML5 mache in gewisser Weise das Versprechen Javas wahr, eine Anwendung einmal zu schreiben und auf allen Plattformen zu betreiben: Von Smartphones bis zu Workstations – der Browser macht’s möglich. Wird in Java-Webframeworks das UI typischerweise auf dem Server gesteuert, beschränken sich moderne Architekturen auf ein REST oder JSON Interface und überlassen das UI Rendern dem Client.

Mit dieser Feststellung allein wäre Kriens noch kein origineller Beitrag zur Diskussion gelungen. Interessant wird nun aber die Aussage, dass die Krise, die HTML5 für Java-Webanwendungen bedeuten wird, eine Chance für OSGi sein könnte. Viele Webanwendungen werden neu geschrieben werden müssen. Und an dieser Stelle biete sich der Wechsel zu OSGi mit seiner modularen, skalierbaren Architektur geradezu an.

I believe that HTML5 will be a disruptive change, causing a lot of web applications to be rewritten since customers will demand the responsiveness of local applications. This offers an opportunity for OSGi; an environment that in almost all aspects seems to have been designed for this paradigm shift. Peter Kriens

Nun kommt diese Aussage fast zeitgleich mit einer Ankündigung David Bosschaerts, die OSGi Alliance arbeite an einer Ausweitung der Spezifikationen auf andere Sprachen-Plattformen. Ist OSGi traditionell auf die Java Community fokussiert, sollen die OSGi Services und Modularitätsfeatures nun auf C/C++ und JavaScript ausgedehnt werden. Ein RFP (Request for Proposals) für die Übertragung des OSGi Service Layer auf JavaScript wurde bereits ins Leben gerufen. Hier ist die Browser IDE Orion Vorreiter, in der einige der Konzepte bereits implementiert wurden.

Auf der C/C++-Seite ist Ähnliches geschehen, der Einsatzbereich liegt hier vor allem bei einem Hardware-nahen Einsatz, etwa in Embedded-Systemen. Der RFP 165 „Native OSGi Core Framework“ hat sich dieser Sache angenommen. Nimmt man noch die Tatsache hinzu, dass OSGi auch mit JVM-Sprachen wie Scala eingesetzt wird, kommt man zum Begriff des „polyglotten OSGi“, den Bosschaert in seinem Blog-Titel verwendet und den wohl auch Peter Kriens im Hinterkopf hat, wenn er von der Ehe zwischen HTML5 und OSGi redet.

Mit Spannung wird zu verfolgen sein, wie sich OSGi in diesen neuen Sphären schlagen wird. Starthilfe könnte hier ein OSGi Framework leisten, das die Einstiegshürden für die Programmierung von OSGi-Anwendungen senken würde – denn geht OSGi zumindest der Ruf voraus, eine relativ schwierig zu beherrschende Technologie zu sein. Nun hat kein anderer als Peter Kriens aber gerade ein solches Grundlagen-Framework angekündigt, mit dem die OSGi-Entwicklung so einfach wie bei Ruby-on-Rails werden soll.

Es fragt sich allerdings, ob ein grundlegendes OSGi Framework nach 15 Jahren OSGi-Geschichte nicht etwas spät kommt. Ein wenig abgeschwächt schien der Enthusiasmus um OSGi in der letzten Zeit zu sein, insbesondere nachdem klar wurde, dass Oracle für das JDK selbst einen anderen, den Jigsaw-Weg gehen wird. Doch ist es Kriens mit seiner Strahlkraft grundsätzlich zuzutrauen, neue Impulse setzen – und schließlich kam das Rails Framework auch Jahre nach der Erfindung der Ruby-Programmiersprache zu voller Blüte.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare
  1. MK2013-07-03 20:30:41

    Ist eigentlich bekannt was der Herr Kriens geraucht hatte, als er zu diesem Schluss kam?
    Klar, es werden die meisten der genannten Frameworks in den nächsten Jahren sterben (einige davon sind ja bereits mindestens scheintot). Aber dies wird bestimmt nicht zum Vorteil von OSGi geschehen. OSGi erleidet dasselbe Schicksal wie Scala: Für den täglichen Einsatz und den 0815-Entwickler ist es schlicht zu komplex und bietet zu viele Fallen, so dass die meisten nach einigen Versuchen frustriert aufgeben und zum guten alten Java zurückkehren. Es fehlt zudem ein Leidensdruck, der einen in Richtung OSGi treiben könnte. Wozu soll ich mich in eine Abhängigkeits-, Sichtbarkeits- und Classloader-Hölle begeben, wenn ich auch ohne das alles in sehr angenehmer Weise Web-Anwendungen entwickeln kann?
    Und auch klar, HTML5 ist nun schon länger das Maß der Dinge in der Web-Welt. Kaum eine neue Web-Anwendung, die nicht umfangreichen Gebrauch von HTML5-Featuren macht. Wie er nun aber zum Schluss kommt, dass HTML5 nun JSF oder Vaadin verdrängen sollte, ist mir schleierhaft. Die Technologien ergänzen sich doch wunderbar, keine Spur von Verdrängungskampf.
    Ich glaube, die Aussage ist einfach ein wenig Marktgeschrei um sich wieder ins Bewusstsein der Entwickler zu rücken. Schon ok, aber man sollte sich dabei nicht lächerlich machen.

    1. Tropper2013-08-01 16:26:50

      "HTML5 mache in gewisser Weise das Versprechen Javas wahr, eine Anwendung einmal zu schreiben und auf allen Plattformen zu betreiben: Von Smartphones bis zu Workstations – der Browser macht’s möglich."

      Wie in schon in der Aussage angedeutet ist "write once, runs anywhere" ja nix neues. Java hat das verstehen vor vielen Jahren auch mal gemacht. Hat es funktioniert? Nein! Warum nicht? Weil es eben doch einen unterschied macht wo Quatsch nachher laufen soll.

      Ob es nun ein VM ist die für die Abstraktion sorgt oder jetzt eben der Browser (der ja immer mehr zu VM verkommt) macht keinen unterschied.

      Browser ist eben nicht gleich Browser. Ein IE verhält sich immer noch viel zu oft ganz anders als ein Safari. Selbst wenn man nur Android als Plattform nimmt ist es abartig wie viele verschiedene Browser Versionen (mit jeweiligen Bugs) es gibt.

      Und dann will man ja nicht das eine App (oder Webite) auf dem Desktop genauso aussieht wie auf dem Mobile.

      Unterm Strich ist es also wieder der selbe Bullshit wie vor 15 Jahren: in der Praxis muss man sich doch wieder jede Plattform einzeln anschauen.

      Aber bis die Masse das gerafft in 10 Jahren gerafft hat gibt es ja sicherlich wieder einen neuen Heilligen Gral und dann wir "write once, runs anywhere" bestimmt endlich wahr .... ganz bestimmt... versprochen...

Schreibe einen Kommentar

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