Zum Inhalt springen
  • Von: Andreas Badelt
  • Java
  • 08.11.2017

EclipseCon Europe – Eclipse Enterprise for Java (EE4J) continued

Bei der EclipseCon Europe 2017 in Ludwigsburg drehte sich vom 24. bis 26. Oktober alles um die Themen Java, IDEs, DevOps, Web-, Cloud-Entwicklung, Eclipse-Technologien und vieles mehr. Mit dabei war auch Andreas Badelt, stellvertretender Leiter der DOAG Java Community. Für DOAG Online berichtet er über seine Eindrücke und Erlebnisse. 

Am ersten Tag der EclipseCon Europe gibt es einiges zum „Eclipse Enterprise for Java“-(EE4)-Projekt zu hören. Eclipse Foundation-Chef Mike Milinkovich berichtet in seiner Keynote von dem Projekt, das auch für die Foundation ein enormes Unterfangen ist, aber auch eine große Chance: „Eclipse Foundation is becoming the source for innovation and collaboration in the Java ecosystem“, heißt es auf einer Folie. David Delabasse, Oracles Java-EE-Evangelist, kann in seinem Vortrag „Java EE 8 is final... Now what?“ neben dem Überblick über EE 8 nur kurz auf die Zukunft eingehen – aber es gibt ja noch eine Panel-Diskussion und abends eine „Birds of a Feather“-Session.

Die Panel-Diskussion wird von Mike Milinkovich geleitet. Beteiligt sind die „Project Management Commitee“-Vertreter der großen an EE4J beteiligten Firmen: Dmitry Kornilov (Oracle), Kevin Sutter (IBM), und Heiko Rupp (Red Hat), außerdem David Delabassee. „Was wäre ein Erfolgskriterium für EE4J innerhalb eines Jahres?“, fragt Mike die Runde unter anderem. Für Delebassee wäre es ein Erfolg, wenn alle Oracle-Projekte bei der Eclipse Foundation liegen und die dann quellcodeoffenen TCKs erfüllen – quasi ein Release-Kandidat für EE4J 1.0, der im Grunde nur Java EE 8 repliziert. Angesichts der schieren Größe des Migrations-Projekts wäre das aber wohl tatsächlich eine anzuerkennende Leistung. Einige der weitergehenden Fragen werden nicht vollständig beantwortet, weil die Panelteilnehmer noch nichts dazu sagen können – oder dürfen. Zum Beispiel die Frage, wie sich das Verhältnis zwischen dem OpenJDK und EE4J gestalten wird. Immerhin so viel ist klar: OpenJDK-Code, der nur für EE relevant ist (dieser wurde mit Java 9 unter java.se.ee zusammgengefasst), soll an Eclipse gehen. Und: Eine Standardisierung von EE4J soll es auch weiterhin geben – das klang schon mal anders. Die Devise heißt aber: „code first“. Welchen Fahrplan der Release-Train hat – alle zwei Jahre, zweimal pro Jahr, ... – dazu traut sich niemand eine verlässliche Aussage zu. „Schneller als bei Java EE soll es gehen, aber das trifft ja auf so ziemlich alle Projekte zu“, heißt es augenzwinkernd.

An der BoF-Session nimmt bis auf Mike Milinkovich die gesamte Panel-Besetzung teil. Hier wird insbesondere das Thema Community-Beteiligung etwas ausführlicher diskutiert. Was kann die Community tun? Zunächst mal etwas Geduld haben, weil die Projekte organisatorisch und technisch laufen müssen. Auch die Übertragung der „IP“ von Oracle wird noch eine Weile dauern. Trotzdem hilft es natürlich, bereits für das Projekt zu werben. Und auch wenn erst mal nur die Mitglieder der Java EE Expert Groups als „Committer“-Kandidaten für die Eclipse-Projekte gesehen werden, erhofft man sich doch eine größere Beteiligung aus der Community. Eine Beteiligung an den Projekten, zum Beispiel in Form von Pull Requests, ist auch sehr einfach. Die Hürden für Committer, mit Schreibrechten in den Repositories, sind aber logischerweise etwas höher. Neben einem gewissen „track record“ aus Open-Source-Projekten gehört dazu ähnlich wie beim JCP das Unterzeichnen eines „Individual Contributor Agreements“, und für abhängig Beschäftigte auch eine „Bescheinigung“ des Arbeitgebers. Letztere könnte in manchen Firmen für Schwierigkeiten sorgen, aber scheinbar ist es gar nicht so schlimm, wie es sich anhört. Es klingt jedenfalls nach einer guten Aufgabe für den iJUG, hier rechtliche Aufklärungsarbeit zu leisten.