Interview mit Mark Struberg

Java EE 8: "Das neue MVC Framework wird eine Ergänzung und kein Ersatz für JSF"

Hartmut Schlosser

Java EE 8 soll im Jahr 2016 erscheinen. Doch laufen schon jetzt die Diskussionen heiß, was genau in der nächsten Version des Java-Enterprise-Standards umgesetzt werden soll. Einblicke aus erster Hand gibt uns heute Mark Struberg, u.a. Mitglied der CDI-Expertengruppe und Sprecher auf dem kommenden Java EE Summit (8. – 10. Dezember in Berlin). Mark dringt tief in die aktuellen Debatten ein und verrät Details zum wohl gecancelten Konfigurations-JSR, zu den Neuerungen in CDI und Apache DeltaSpike sowie zur Diskussion um die vermeintliche Konkurrenzsituation zwischen JSF und dem brandneuen MVC Framework.

JAXenter: Der Scope von Java EE 8 nimmt langsam Formen an. Dabei scheint klar zu sein, dass Java EE 8 ohne Konfigurations-JSR auskommen muss – das hatte Anatole Tresch von CreditSuisse im September bekannt gegeben. Weshalb wäre ein solcher JSR aus deiner Sicht wichtig gewesen? Welche Probleme sollten gelöst werden?

Mark Struberg: Die Gründe, die für ein derartiges Konfigurationssystem sprechen, sind derart mannigfaltig, dass ich hier mehrere Seiten füllen könnte. Wie konfiguriert man derzeit REST Endpoint URLs, Produktfeatures, Berechtigungen, Credentials, etc. in „portabler“, sprich: Server-übergreifender Weise?

JNDI disqualifiziert sich hier in der Praxis regelmäßig selbst, da es sich je nach Java-EE-Server-Hersteller, und teilweise sogar abhängig von der Version, unterschiedlich verhält. Registriert man auf dem Server z.B. eine DataSource, dann „mapped“ diese fast jeder Server an eine andere Location. Außerdem funktioniert es nur sehr bedingt in Java SE (benötigt für Backend Unit-Tests).

Einige Server wie WebLogic bieten auch Deployment-Time Replacement von Platzhaltern (${myconfig}) in diversen Container XML Files. Derzeit funktioniert dies eben nur proprietär in diesen Container. Vermutlich werden wir diesen optionalen Mechanismus generalisiert und somit portabel zur Verfügung stellen.

Das Konfigurationssystem von Apache DeltaSpike, über das ich sicher auch auf dem Java EE Summit sprechen werde, bietet hier einstweilen eine einfache aber trotzdem sehr funktionsstarke Alternative.

Mark StrubergMark Struberg ist Softwarearchitekt mit über zwanzig Jahren Programmiererfahrung. Er arbeitet seit 1996 mit Java und ist aktiv in Open-Source-Projekte im Bereich Java und Linux involviert. Mark ist Apache Software Foundation Member und PMC bei Apache OpenWebBeans, MyFaces, Delta-Spike und vielen anderen Apache-Projekten. Als Java Expert Group Member arbeitet er aktiv an der CDI und anderen EE-Spezifikation mit. Er arbeitet unter anderem für die Research Group for Industrial Software (INSO) der TU Wien.

JAXenter: Wie sind die Diskussionen um den Konfigurations-JSR seither weiter gelaufen? Anatole Tresch hatte ja angekündigt, seine Ideen auf der vergangenen JavaOne weiter zu diskutieren. Wird dennoch weiter daran gearbeitet? Werden zumindest Teilprobleme in Java EE 8 gelöst? Oder müssen wir uns bis zu Java EE 9 gedulden?

Mark Struberg: Es wird sogar sehr aktiv daran weiter gearbeitet. Anatole hat gemeinsam mit vielen Kollegen von Apache DeltaSpike, einigen Freunden von JBoss und diversen anderen Java-EE-Veteranen das Apache Incubator Projekt Tamaya ins Leben gerufen [1]. Die finale Homepage wird dann unter http://tamaya.incubator.apache.org/ zu finden sein (work in progress).

Das Ziel ist es, die diversen Ideen zusammenzuführen und ein wirklich portables Konfigurationssystem zu erstellen. Der Fokus liegt dabei übrigens gar nicht auf Java EE sondern vielmehr auf Java SE! Der Grund dafür ist einerseits, dass wir dies auch in SE bestens brauchen können. Andererseits werden die konfigurierten Werte sehr oft bereits während des Container-Boot benötigt. Wir steuern damit ja z.B. auch unsere CDI Extensions. Der Mechanismus soll natürlich auch für Spring, JavaFX und andere Non-EE-Projekte funktionieren.

Sollten wir mit dem Ergebnis zufrieden sein, dann steht auch eine Umbenennung der Packages in javax.configuration.* im Raum. Aber bis es soweit kommt, müssen noch einige rechtliche Probleme auf Seiten Oracles aus dem Weg geräumt werden. Tamaya wird auf jeden Fall ein flexibles API, eine Reference Implementation sowie ein TCK dafür beinhalten. Alles natürlich wie für Apache-Projekte selbverständlich unter der erprobten Apache License V2.0 (ALv2).

Man vergisst in der ganzen JSF-vs.-MVC-Diskussion oft, dass es nicht nur zwei Ansätze gibt, sondern drei.

JAXenter: Eine Erweiterung, die sicher kommen wird, ist das neue MVC Framework. Für welche Anwendungszwecke ist das Framework gedacht? Kann man schon abschätzen, wie in etwa es aussehen wird?

Mark Struberg: Beim Thema MVC bin ich nur am Rande involviert, und ich bin genauso gespannt wie ihr, was dabei raus kommt. Generell sieht man bei derartigen Diskussionen meist nur die Vorteile und vergißt die damit implizit ebenfalls verbundenen Nachteile. Aus meiner Erfahrung beim Bau derartiger Applikationen kenne ich diese leider auch.

Vermutlich hat sich seit 2006 herum, als ich mit Spring + Spring MVC + JSP + tiles + JavaScript (de facto AJAX, aber damals nannten wir es noch nicht so) einige Applikationen gebaut habe, vieles gebessert. Der problematische Bereich damals war jedoch nicht der MVC-Teil am Server sondern die Web-Applikation selbst (html + JavaScript).

Man vergißt außerdem in der ganzen JSF vs. MVC Diskussion oft, dass es nicht nur zwei Ansätze gibt, sondern drei:

  1. JSF stellvertretend für Server-Side-Komponentenframeworks (MVC-2).
  2. MVC-1-Ansätze mit Server-Side-Rendering wie z.B. Spring-MVC oder auch der neue JSR-371.
  3. Reine REST-Ansätze mit e.g. JAX-RS am Server und pures html/AJAX. Hier sitzt der Controller quasi am Client.

Der EE-MVC-Ansatz ist also in Wirklichkeit noch viel spezifischer als viele auf den ersten Blick ahnen. Ich bin tatsächlich ebenfalls gespannt, wie sich das gesamte Thema entwickelt.

JAXenter: Manche haben das neue MVC Framework als Konkurrenten zum etablierten JSF bezeichnet. Siehst du das auch so? Wird JSF damit langfristig auf’s Abstellgleis geschoben?

Mark Struberg: Nein, hier bin ich eindeutig d’accord mit Ed Burns, dass der neue MVC eine Ergänzung und kein Ersatz zu JSF sein wird.

Ich habe in den letzten paar Jahren einige Projekte mit anderen UI Web Frameworks gemacht, und dabei habe ich viele Funktionen, die in JSF einfach Standard sind, vermißt. Z.B. ist es mit vielen alternativen Frameworks einfacher, hübsche HTML-Seiten zu machen (wobei dies mit JSF-2.2 auch recht einfach ist). Aber bei vielen dieser Frameworks misse ich das gesamte Datenhandling.

Der „kampferprobte“ Lebenszyklus von JSF bietet hier in datengetriebenen Business-Projekten einen nicht zu unterschätzenden Vorteil. Wenn es um Business-Applikationen geht, macht eine hübsche HTML-Seite alleine eben noch kein gutes UI aus.

Ganz allgemein möchte ich auch darauf hinweisen, dass einfache Samples kein Garant für einfache Echtapplikationen sind. Wer je versucht hat, ein Java-EE-Codebeispiel 1:1 in einer echten Anwendung einzusetzen, der weiß, wovon ich spreche. Samples sollen den Kern der beleuchteten Technologie möglichst einfach wiedergeben und lassen bewusst das ganze „Drumherum“ weg.

In echten Projekten ist dies aber nicht möglich. Probleme mit  LazyInitialisationExceptions, Clustering, Serialization, Transaktionsgrenzen, Locking und potentiellem Datenverlust bzw. Dateninkonsistenz lauern an jeder Ecke. All diese Dinge werde ich am Java EE Summit ebenfalls beleuchten.

Bis jetzt gibt es fünf Dinge in Java EE 8, auf die ich mich wirklich freue!

JAXenter: Welche Neuerungen kommen sonst noch in Java EE 8 auf uns zu? Was würdest du selbst da herausheben?

Mark Struberg: Ich denke, dass es noch ein wenig zu früh ist, einen zuverlässigen Ausblick auf Java EE 8 zu geben. Bis jetzt gibt es fünf Dinge, auf die ich mich wirklich freue:

  1. Servlet 4.0 und hier vor allem die HTTP-2-Unterstützung.
  2. JCache, und zwar jetzt hoffentlich wirklich! Das wurde ja leider schon des Öfteren verschoben.
  3. JCA: Eine sehr unbekannte Spezifikation, aber dennoch sehr wichtig, wenn es um die Internas von EE Server geht.
  4. Java Configuration – weil ich noch immer daran glaube 😉
  5. CDI 2.0: Wir haben viele Ideen, aber diese müssen noch auf Herz und Nieren auf Praxistauglichkeit abgeklopft werden.

Generell wird es natürlich überall den Support von Lambdas geben. Wobei zu erwähnen ist, dass Java 8 sogar jetzt von einigen EE-6-Containern bereits unterstützt wird.

JAXenter: Du bist ja u.a. Teil des Apache-Projektes DeltaSpike, das Erweiterungen für CDI bereit stellt und als Nachfolger von MyFaces CODI und JBoss Seam gilt. Gerade ist Version 1.1 von DeltaSpike erschienen. Was macht das neue Release aus?

Mark Struberg: Nach dem Release ist vor dem Release. Wir arbeiten gerade an 1.2.0, das demnächst erscheinen sollte.

Generell verwenden wir Semantic Versioning und erhöhen die Minor Revision Number mit jeder Änderung, die für den Benutzer entweder eine API-Änderung zur Folge hat, oder wenn wir neue Funtionalität zur Verfügung stellen. Für DeltaSpike-1.1 haben wir vor allem im Bereich JSF Support eine ganze Menge an Funktionalitäten hinzugefügt.

Vor allem das überarbeitete Conversation Handling sticht hervor. Das Test-Modul wurde auch erweitert.

JAXenter: Wie wird sich DeltaSpike in Hinblick auf die geplanten CDI-Features in Java EE 8 verändern?

Mark Struberg: Am besten ihr fragt mich dazu in drei Jahren nochmal. Eine nicht unerhebliche Anzahl an Features in Java EE 7 wurden ja durch DeltaSpike inspiriert. Und mit dem Config-JSR und weiteren CDI-2.0-Änderungen (z.B. Java SE Boot analog zu DeltaSpike CdiCtrl) wird auch in Java EE 8 einiges dabei sein, das es in DeltaSpike bereits heute (sogar für Java EE 6 Container) gibt.

Bereits heute greifen einige DeltaSpike APIs intern auch auf Java-EE-7-Methoden zu, wenn diese vorhanden sind. Das DeltaSpike API ist aber weiterhin total unabhängig von EE-Funktionen. Als Beispiel verwendet BeanProvider#getContextualReference(Class) in EE7 automatisch CDI.current(), um den BeanManager zu finden.

Was ich bereits heute voraussagen kann, ist, dass ein Projekt, das jemand heute mit DeltaSpike schreibt, auch auf Java EE 8 Containern ohne Probleme laufen wird.

Während „Magie“ bei Zaubertricks nettes Beiwerk ist, wird dies bei Software-Projekten äußerst gefährlich.

JAXenter: Auf dem Java EE Summit veranstaltest du ein „Deathmatch“ zwischen den beiden Komponentenmodellen CDI und EJB. Wer überlebt? 😉 Oder anders gefragt: Wo macht was Sinn?

Mark Struberg: Beides macht Sinn, es kommt eben immer auf die richtige Verwendung an. Mein Workshop geht nicht in die Richtung einer stumpfen Aufzählung von Features – das könnte jeder selbst recht einfach bei Tante Google zusammensuchen –, sondern um eine sehr einfache aber doch präzise Vermittlung der zugrundeliegenden „Tricks“, die in CDI und EJB verwendet werden.

Wie ihr wisst, schreibe ich ja nicht nur aktiv an der CDI-Spezifikation mit, sondern habe auch erhebliche Teile von Apache TomEE mitentwickelt. Und auch der IBM WebSphere Application Server verwendet viele der von mir mitgeschriebenen Projekte (wenn auch mit einem wesentlich „defensiveren“ Update-Zyklus).

Ich habe also einen recht guten Einblick, wie so ein Server intern „tickt“. Und genau darum wird es gehen – aber in sehr vereinfachter und selbst für Java-Normalsterbliche verständliche Form.

Wenn ein Zauberer einen Trick vorführt, dann sieht das für den Zuseher magisch aus – doch dahinter steckt meist nur ein sehr einfacher Mechanismus. Sobald man diesen erklärt bekommt, ist die Funktionsweise einfach nachzuvollziehen, und unerwünschte Seiteneffekte werden offensichtlich und dadurch vermeidbar.

Während „Magie“ bei Zaubertricks nettes Beiwerk ist, wird dies bei Software-Projekten äußerst gefährlich. Warum verhält sich etwa ein EntityManager in verschiedenen Projekten komplett anders? Warum muss man ihn teilweise sogar mit anderen Methoden steuern? Warum darf man in @Stateless EJBs auf keinen Fall State speichern? Wie sieht es mit Nebenläufigkeit in CDI und EJB Beans aus? Und vieles mehr!

JAXenter: Mark, vielen Dank für diese interessanten Einblicke!

Java EE Summit
14 Power Workshops zu Java EE 6/7, JPA, EJB, CDI, JSF, Services: REST und WS-*, Clean Code und DDD, Business Process Management, Java EE Architecture, New Web Technologies, Continuous Development, Java EE Events und Messaging… Der nächste Java EE Summit vermittelt an drei Tagen Java-EE-Profi-Know-How in kompakter und intensiver Form.

In drei parallel laufenden Tracks – EE 7 at a Glance, Best Practices und Java EE & Friends – lernen Sie tiefgehend, wie Sie mit Java EE 6 und 7 Real-Life-Enterprise-Anwendungen optimal planen, realisieren und zu einem erfolgreichen Abschluss bringen.

Am dritten Tag wird das erlernte Know-how der ersten beiden Tage in „Do-it-yourself“-Workshops zusammengefasst. An diesem Tag erleben Sie besonders viel Live Coding, kombiniert mit praktischen Übungen.

Infos unter: www.java-ee-summit.de

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: