Suche
Interview mit Werner Keil

JSR 385: Was für das neue Units of Measurement API 2.0 geplant ist

Dominik Mohilo

Werner Keil

Daten und Zahlen korrekt auszugeben ist gerade in Bereichen wie dem Internet of Things oder in der Systemüberwachung wichtig. Werner Keil, einer der Spec-Leads des Units of Measurement API 2.0 (JSR 385), spricht im Interview darüber, was die Weiterentwicklung des Unit API 1.0 an Neuerungen bringen wird und wann sie voraussichtlich verfügbar ist. Er gibt zudem einen kleinen Einblick, warum das API so essentiell wichtig ist und wofür bzw. wo es eingesetzt werden kann.

JAXenter: Hallo Werner und danke, dass du dir die Zeit genommen hast. Das Unit API 1.0 ist im Begriff, überarbeitet zu werden. Vielleicht kannst du kurz erklären, welchem Zweck das API dient?

Werner Keil: Das Unit API 1.0 (JSR 363) dient dem sicheren Umgang mit Maßeinheiten überall dort, wo die Semantik von Daten und Zahlen wichtig ist. Vom Internet of Things mit Messwerten und Sensoren über den Gesundheitsbereich, die Performance-Messung und Systemüberwachung oder Location-Based-Data sowie generell Datenanalyse und Big Data.

Etliche, teils sehr verbreitete Frameworks und Plattformen, benutzen das JSR inzwischen in der Produktion. Darunter Eclipse SmartHome und darauf basierende Lösungen wie OpenHAB oder Magenta SmartHome der Telekom. Oder die Java-Unterstützung Parfait für das populäre Performance-Managementsystem Performance Co-Pilot (PCP). Auch für populäre JVM-Sprachen wie Groovy oder Kotlin existieren Bibliotheken zur Unterstützung des JSR 363, wodurch man in den funktionalen Sprachen oft DSLs oder Kalkulationen, die Maßeinheiten beinhalten, leichter und intuitiver durchführen kann als in Java selbst.

JAXenter: Im JSR 385 wird nun der offizielle Nachfolger, das Units of Measurement API 2.0, entwickelt. Welche Verbesserungen bzw. Änderungen sind geplant?

Abgesehen von Verbesserungen und Erweiterungen des APIs ist die massivste Veränderung in der Definition einiger SI-Einheiten zu erwarten, die im Zuge einer Reform des Metrischen Systems zwischen Ende 2018 und Anfang 2019 geplant ist. Auf der nächsten Generalkonferenz für Maß und Gewicht im November dieses Jahres sollen diese Definitionen voraussichtlich festgelegt werden. Wie beim JDK oder Java EE weiß man nicht hundertprozentig, ob alle Mitglieder die Änderung annehmen, aber es wurde (wie Java 9 oder Jigsaw 😉 ) bereits davor verschoben, und man darf von einem Beschluss der Änderungen ausgehen, die laut Plan am 20. Mai 2019 (da jährt sich der Gründungstag der Metrischen Konvention) offiziell in Kraft treten.

Da das die größte Reform des SI-Systems seit dessen Einführung unter diesem Namen im Jahr 1960 ist, entschieden wir uns beim JSR 385 für den Versionssprung zum Unit API 2.0. Etwa vergleichbar mit Servlet 4.0 und anderen Java-Standards, meist im Java EE Umfeld, die an externe Standards wie HTTP 2.0 angepasst wurden. Die meisten dieser Änderungen betreffen die Spezifikation und verwandte Bereiche wie JavaDoc. Die numerischen Werte dürften sich nur an sehr wenigen Stellen ändern und auch dort nur bei Nutzung der allerhöchsten möglichen Präzision.

Extreme Java Camp
 
Dr. Heinz Kabutz

Das Extreme Java Camp umfasst zwei Intensivseminare, die umfassendes und aktuellstes Know-how zu fortgeschrittenen Java-Themen und zu Java Concurrency Performance vermitteln.

Darüber hinaus wird das API selbst auch verbessert und um weitere Funktionen ergänzt. Das Präfix (etwa Mikro, Dezi, Milli, …) wird im API/SPI verfügbar gemacht. Eine bessere Unterstützung von Compound-Einheiten und Werten (also „Tag, Monat, Jahr“ oder „Fuß, Zoll“ bei Größenangaben im anglo-amerikanischebn Raum) ist ebenso vorgesehen. Und damit verbunden die Ergänzung eines Formatters für Quantitäten statt bisher nur Einheiten im API.

Weitere Änderungen betreffen eine stärkere JDK-Unterstützung, so etwa die Interaktion mit Typen wie Date/Time oder Java 9+ und Jigsaw. Wo das JDK ab Java 10 weitere Verbesserungen bietet, etwa Typinferenz oder dergleichen, werden wir sie zumindest in der RI vom JSR 385 auch berücksichtigen. Durch Multi-Version-JARs könnten wir auch da auf gewisse Java-Versionen eingehen, während zumindest Java 8 als Minimalversion für API und auch RI ausreichen sollte.

JAXenter: Wie lange werden die Nutzer wohl warten müssen? In welchem JDK wird das API aller Voraussicht nach erscheinen?

Nicht so lange wie bei Version 1.0, die etwas über zwei Jahre, nachdem das JCP EC den Standard angenommen hatte, als Final Release verfügbar war. Die erwähnten Reformen des SI-Einheitensystems haben einen Zeitplan bis spätestens Q1/2019, woran wir uns für JSR 385 auch orientieren. Selbst wenn das erneuerte Metrische System wider Erwarten später in Kraft treten sollte, planen wir eine Finale Version von JSR 385 spätestens für Mai 2019. Sollten die SI-Änderungen später wirksam werden, dann wäre das problemlos mit einem MR von JSR 385 zu ergänzen. Das API wird allerdings unabhängig davon fertig.

Die leidige Frage nach dem JDK stellt man uns seit den Tagen von JSR 275. Auch andere JSRs wie 354 oder 363 waren damit konfrontiert. Ich wurde im Mai 2017 beim JUG Meeting und JCP EC F2F in Austin danach gefragt, wo auch Java SE Account Manager George Saab und JDK Chefarchitekt Brian Goetz anwesend waren. Meine Antwort, dass ab JDK 9 die mitgelieferten Features fast keine Rolle mehr spielen, erhielt von beiden volle Zustimmung. Module nach Jigsaw bietet der JSR 385. Möglich ist auch, dass sogar ein MR oder Minor Update des JSR 363 APIs damit aufwarten wird. Damit kann das Modul unit-api überall genutzt werden, wo es gebraucht wird.

Lesen Sie auch: JavaMoney, Money, Money: Eine Einführung in den JSR-354-Standard

Orte wie Eclipse Marketplace lassen auch das dynamische Hinzufügen solcher Features zu, während manche Projekte, wie etwa Eclipse SmartHome, diese standardmäßig vorinstalliert haben. Ob etwas im JDK enthalten ist, kann heute schon als unbedeutend bezeichnet werden. Ob ein JSR wie 385 in einem Smart-Home- oder Big-Data-Profil auf Basis von Java SE oder auch EE4J enthalten ist, wird in Zukunft die richtige und wichtigere Frage sein.

Weitere Informationen zum JSR 385 bzw. dem Units of Measurements API 2.0 gibt es im entsprechenden Java Specification Request auf der Homepage des JCPs.

Werner Keil ist Agile Coach, Java-EE- und IoT/Embedded/Real-Time-Experte. Er hat über 25 Jahre hinweg als Programm-Manager, Coach, Softwarearchitekt und Consultant Global-500-Unternehmen aus allen Industriezweigen und führenden IT-Unternehmen geholfen. Werner ist Eclipse- und Apache-Committer und JCP-Mitglied in JSRs wie 333 (JCR), 342 (Java EE 7), 354 (Money), 358/364 (JCP.next), Java ME 8, 362 (Portlet 3), 363 (Units sowie Spec Lead), 365 (CDI 2), 375 (Java EE Security) und Mitglied des Executive Committees.

Verwandte Themen:

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Schreibe einen Kommentar

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