"Vakuum bei Java EE, in dem Pseudostandards oder semiproprietäre Lösungen weiter Verbreitung finden"
Thorben Janssen im Gespräch mit Werner Keil über seine Arbeit im JCP Executive Committee (EC), die Zukunft von Java EE 8 und welche Rolle das EC dabei spielen kann und dem kürzlich veröffentlichten Units of Measurement JSR.
- Thorben Janssen
Es gibt viele interessante Menschen in der Java Community, die mit ihrem Engagement in Java Specification Requests (JSRs) und Open-Source-Projekten die Entwicklung immer weiter vorantreiben. Einige von ihnen möchte ich hier nach und nach vorstellen und mit ihnen über ihre Projekte sprechen. Dieses Mal habe ich mit Werner Keil über sein Engagement im JCP Executive Committee und den vor kurzem abgeschlossenen JSR 363 – Units of Measurement API – gesprochen.
Thorben Janssen: Werner, erzähle uns doch ein bisschen über dich. Wie bist du zur Softwareentwicklung gekommen, und was machst du heute?
Werner Keil: Das war bereits relativ früh. So wie etwa der Raspberry Pi gedacht war, Kindern und Jugendlichen das Programmieren nahezubringen, gab es früher Computerkurse in den Ferien, die ich besuchte. Damals erlernten wir mit Sprachen wie Basic oder Logo (das mit der "Turtle") die ersten Grundprinzipien der Programmierung meist mehr oder weniger spielerisch.
Nicht lange danach ergaben sich daraus erste Aufträge für Kunden oder Praktika bei Firmen. Ich war in der glücklichen Lage, durch einen Kunden in Österreich sehr früh (ab 1996) mit Java zu arbeiten und damit von Anbeginn Erfahrung zu sammeln. Andere Entwicklungen – etwa NEXTstep und Sprachen wie Objective-C, Oracle-Datenbanken oder das World Wide Web – lernte ich beim Studium auch in einer frühen Phase kennen, beim WWW oder Google praktisch, als sie entstanden.
Heute helfe ich Kunden in aller Welt mit Java, Java EE oder Optimierung mittels agiler Methoden, DevOps oder durch Aufteilung monolithischer Systeme im Sinne von Microservices oder "Self-Contained-Systems".
Janssen: Was machst du privat, wenn du nicht gerade in der Java-Welt unterwegs bist?
Keil: Ich reise viel, nicht nur beruflich. Abgesehen von technischen Themen, Büchern und Artikeln, die auch eher in der Freizeit oder nach dem Tagesgeschäft anstehen, bleibt manchmal Zeit, Fiction (Romane, Drehbücher) oder Songtexte zu schreiben.
Als Associate Member im JCP
Janssen: Du bist bereits seit einigen Jahren im Executive Committee (EC) des JCP tätig und wurdest nun als Associate Member wiedergewählt. Kannst du uns die Aufgaben und die Arbeitsweise des EC kurz vorstellen?
Keil: Das EC ist mehr oder weniger das "Board" oder deutsch der "Aufsichtsrat" für Java-Technologien. Oracle hat den ständigen Vorsitz, daneben sind weitere 24 Mitglieder entweder gewählt oder ratifiziert. Das heißt, Oracle schlägt sie vor – und sofern sie von den Mitgliedern nicht für ungeeignet empfunden werden (das ist bisher zumindest einmal passiert) – in der Regel bestätigt.
Frühere Interviews
Die Hauptaufgabe besteht im Bewerten und in der Abstimmung über neue oder die Weiterentwicklung bestehender Java-Standards (JSRs). Daneben gibt es auch administrative JSRs – etwa jener, der die neuen Associate-Mitglieder und EC-Sitze zu deren Vertretung hervorbrachte.
Janssen: Vor der Neustrukturierung des EC wurden die Mitglieder in der Regel von großen Unternehmen gestellt. Was hat dich damals dazu bewegt, für das EC zu kandidieren, und was macht die Arbeit für dich besonders?
Keil: Das ist nicht ganz korrekt. Einzelne Personen gab es schon relativ lange. Doug Lea (zuletzt ratifiziert, was mich inzwischen zum längst dienenden frei gewählten Individual-EC-Mitglied macht) war fast von Anbeginn des JCP dabei. Als Professor aus dem akademischen Umfeld mag er nicht so sehr die Gemeinschaft repräsentieren, wie JUGs oder engagierte Einzelpersonen heute. Mit der Apache Software Foundation kam aber auch eine Open-Source-Organisation mit starkem Java-Fokus relativ früh dazu.
Ich bin seit etwa 2005 JCP-Mitglied und trat den ersten JSRs wie 275 (Vorgänger für 363) bei, dort später auch als Spec Lead. Ich half zu jener Zeit BEA Systems (heute Oracle) mit Kundenprojekten, die etwa in den Java-Portlet-Standard (JSR 168) eingeflossen sind, oder anderen wie Java Content Repository. Danach war ich, erneut für BEA, als einziger externen Berater in der gesamten EMEA-Region freiberuflich tätig. Was nicht durch deren hohe Erwartungen an die Berater lag (man hat etliche andere interviewt, mich dabei teils auch hinzugezogen).
Dies und die Tätigkeit in JSRs bestärkten mich 2008 darin, es auch mit einer EC-Kandidatur zu versuchen. Ich wurde praktisch in derselben Woche, in der Barack Obama zum Präsidenten wurde, ins EC gewählt.
Janssen: Oracle hat auf der JavaOne neue Pläne für Java EE 8 vorgestellt und diese nun auch als EDR 2 des JSR 366 – Java Platform, Enterprise Edition 8 – veröffentlicht. Wie siehst du die Zukunft von Java EE, und welchen Einfluss kann das JCP Executive Committee darauf nehmen?
Keil: Da Oracle letztlich nur eine Stimme im Executive Committee hat, kann das EC tatsächlich gewissen Einfluss auf die Zukunft von Java EE 8 und darüber hinaus nehmen. Ein Java-EE-Kandidat, JSR 350 (State Management), wurde nach längerer Verzögerung und einiger Spec-Lead-Wechsel intern bei Oracle durch Scheitern des Renewal Ballot gestoppt.
Bei der JavaOne präsentierte Oracle etwas andere Pläne für "State Management" in Verbindung mit der Cloud, die man eventuell für Java EE 9 erneut aufgreifen will. Sollte das EC derartige JSRs auch von Oracle nicht für plausibel halten, könnte es schon am Creation Review scheitern.
Die Ankündigungen von der JavaOne wurden jüngst etwas relativiert. Configuration oder Health Monitoring sind, wenn es nach Oracle geht, wohl nicht vor Java EE 9 geplant. Das ist schade, weil bis dahin ein Vakuum entsteht, in dem Pseudostandards oder semiproprietäre Lösungen wie Spring und dergleichen weiter Verbreitung finden.
Da Oracle andererseits klar gemacht hat, in seinen JSRs die TCK genannten Kompatibilitäts-Tests nicht Open Source oder frei verfügbar anzubieten, könnten andere JCP- (oder EC-)Mitglieder hier anbieten zu helfen, wenn sie Mittel und Erfahrung dafür sehen. Bewegungen wie Java EE Guardians oder die Microprofile-Initiative könnten hier helfen, dass mehrere, kleinere Anbieter eventuell auch gemeinsam einen solchen Standard leiten.
Units of Measurement API
Janssen: Du warst auch als Specification Lead für den kürzlich veröffentlichten JSR 363 – Units of Measurement API – tätig. Kannst du uns den JSR bitte kurz vorstellen?
Keil: JSR 363 ist einer der "Werte" oder datengetriebenen JSRs. Er ist grob vergleichbar mit spezialisierteren JSRs wie 310 (als Teil des JDK) oder 354 (Money and Currency), allerdings flexibler, was die Anwendungsgebiete betrifft. Der JSR hilft, die Maßeinheit numerischer Werte typsicher abzubilden und auch umrechnen zu können, etwa von Grad Celsius in Fahrenheit oder Kilogramm in Pfund oder Stone. Manche Sprachen, darunter F# oder neuere C++ Versionen, bieten ähnliche "Typ Literale" oder sogar dezidierte Einheitenunterstützung.
Ein wichtiger Bereich war uns die Embedded-Entwicklung und das "Internet der Dinge". Daher ist der JSR 363 als einer der ganz wenigen neueren JSRs kompatibel mit Java ME 8 Embedded, ebenso wie allen Java-SE- oder -EE-Umgebungen, die mindestens auf Java 6 laufen.
Embedded-Geräte haben meist einen deutlich längeren Lebenszyklus. Ich weiß von vielen Kunden, dass etwa Bahn- oder Automotive-Projekte, wenn sie Java nutzen dürfen, sehr lange bei einer Java-Version bleiben müssen. Die Sicherheitsüberprüfungen sind sehr langwierig und werden nicht einfach gemacht, weil Oracle oder Microsoft gerade eine neue Produktversion anbieten.
Darüber hinaus sind Einheiten und der JSR 363 für andere JSRs von Interesse, wo immer es um Daten oder Werte und deren Semantik geht – von Bean Validation über Big Data bis Konfiguration, Health oder Performance Monitoring, um nur einige zu nennen.
Janssen: Was sind die weiteren Pläne für den JSR 363? Ist bereits ein weiteres Release geplant oder ist die Spezifikation erst mal abgeschlossen?
Keil: Die Spezifikation ist vorerst abgeschlossen. Da wir physische Größen und Maßeinheiten in Java abbilden helfen, richten wir uns damit ja an Standardorganisationen wie ISO, BIPM oder NIST, die Jahrzehnte, manchmal sogar Jahrhunderte gebraucht haben, um gewisse Standards wie das metrische System zu definieren.
Aus fachlicher Sicht könnten sich aus dem geplanten BIPM-Kongress zur Reform des SI-Standards 2018 Änderungen ergeben. Sicherlich für JavaDoc und dergleichen. Ob es auch auf die API Einfluss haben mag, werden wir sehen. Ein MR, auch von der Unit-API, ist also bis spätestens Ende 2018 zu erwarten.
Davor könnte Java SE 9, zum Beispiel durch das Jigsaw-Modulsystem, technische Anforderungen ergeben, die Anpassungen nahelegen. Was Modularität und Optionalität betrifft, ist der JSR 363 ohnehin Java SE 9 und Jigsaw deutlich voraus. Denn man kann vom 5- bis 10-k-Mini-JAR bis zum (auch nur 30 Kbyte) Full Profile je nach Umgebung die Teile des JSR wählen, die man benötigt. Dank Jigsaw könnte das noch leichter konfigurierbar werden. Die Grundlagen bieten wir aber schon heute.
Die Eclipse Foundation arbeitet auf Wunsch von IoT-Projekten wie SmartHome gerade daran, den JSR 363 und notwendige Module auch für Eclipse-Projekte nutzbar zu machen. Namhafte Unternehmen, etwa auch im Automotive- oder Pharmabereich, nutzen den JSR 363 auch heute schon bis in die Produktion. Also dürfte der Schwerpunkt da eher im Bereich Einheitensysteme oder Erweiterungsmodule liegen. Etwa für bestimmte Branchen oder ISO-Zertifizierung.
Janssen: Wo kann man mehr zum JSR 363 und den Aktivitäten des JCP Executive Committee erfahren?
Keil: Der Einstiegspunkt für JSR 363 ist unitsofmeasurement.github.io beziehungsweise Kurzformen wie uom.technology oder uom.si (für das SI-System und dessen Unterstützung). Das Executive Committee, seine Mitglieder und Aktivitäten sind unter jcp.org/en/participation/committee zu finden.
Community-Arbeit
Janssen: Welche weiteren Projekte verfolgst du?
Keil: Fast zu viele, um sie alle aufzuzählen. Wenn man von JSRs absieht, sind wohl noch UOMo (in Verbindung mit dem erwähnten Eclipse-Support für JSR 363) und andere Eclipse-Projekte erwähnenswert. Dort besonders im Science-, Healthcare- oder Biotech-Bereich im Rahmen der Eclipse Science WG.
Da Microprofile nun auch ein Eclipse-Projekt ist, helfe ich dort auch in Teilbereichen, insbesondere Monitoring oder Konfiguration. Ich habe Letzteres auch in Projekten wie PCP (Performance Co-Pilot) und Parfait durch Contribution unterstützt.
Nach einem Exkurs bei Apache habe ich zum Jahresende das OpenDDR-Projekt, dessen Mitbegründer ich bereits 2011 war, wieder aktiviert, um die Specs neuer Mobile- oder IoT-Geräte offen und transparent pflegen zu können. Leider hat das bei Apache nicht so geklappt, primär weil die Idee von Daten versus ausführbarem Code dort nicht so Fuß fassen konnte, wie etwa bei Eclipse (das dank "Babel" sogar teilweise für Klingonen in ihrer Muttersprache benutzbar ist;-) ).
Janssen: Wo kann man dich finden?
Keil: Aktuell primär im Rhein-Main-Neckar-Gebiet in Deutschland. Online blogge oder poste ich primär unter verschiedenen Open-Source-Projekten, aber bei Twitter oder Facebook bin ich recht häufig aktiv. Mein eigenes Unternehmen hat die Website www.catmedia.site. Dort findet man auch weitere Kontaktoptionen wie LinkedIn oder XING.
Janssen: Vielen Dank für das Interview und weiterhin viel Erfolg im JCP Executive Committee und deinen vielen weiteren Projekten. ()
