In Zeiten der „Fake News“ sollte man stets den Wahrheitsgehalt von dem hinterfragen was man liest – insbesondere an einem bestimmten Tag im Jahr, wie gestern einer war. :-)

Der JEP-472 und die Entfernung der neuen Date & Time API aus meinem gestrigen Beitrag waren natürlich frei erfunden. Spätestens beim Anklicken der Quellen-Links wäre dies klar geworden.

Tatsächlich ist die java.time-API ein Beispiel für sehr gutes Code Design. Unter anderem werden die folgenden Prinzipien darin konsequent eingehalten:Mehr

(Achtung! Bitte nach der Lektüre unbedingt auch diesen Folgebeitrag lesen!)

Wie Oracle verlauten ließ, soll die mit Java 8 eingeführte Date & Time API wieder aus Java entfernt werden (JEP-472, JEP = Java Enhancement Proposal).

Komplexe API

Wie es aussieht wird die neue API, die auf Joda-Time basiert, von der Entwicklergemeinde nicht angenommen. Grund dafür ist, dass die API übermäßig komplex ist und aus zu vielen Klassen und Interfaces besteht, was die Anwendung der API sehr unhandlich macht. Oft weiß man nicht, welche Klasse bzw. welches Interface man nun eigentlich verwenden soll.

Laut Umfrage einer repräsentativen Gruppe von Java-Entwicklern setzen lediglich 3,42% der Entwickler bereits die neue API ein. Zusätzlich würden 2,11% der befragten Entwickler die API einsetzen, „wenn sie irgendwann einmal die Zeit fänden, sich einzuarbeiten“. Über 90% antworteten, dass sie die von Anfang an enthaltene API mit Date und Calendar gewöhnt seien und sich nicht umstellen wollten.

Stimmen der Vordenker

Bereits im Vorfeld hatten sich Größen aus der Entwicklerszene negativ über die API geäußert. So schrieb Martin Fowler in seinem Bliki (Mischung aus Blog & Wiki): „Who wants to learn an API with that many classes and interfaces? We had all we needed before Java 8, with Date and Calendar from the java.util package. And all experienced Java developers know how to use them and what their pitfalls are.“

Robert C. Martin, auch bekannt als „Uncle Bob“, twitterte: „It’s nearly impossible to write clean code with the Java 8 Time API“.

Brian Goetz, Java Language Architekt bei Oracle, begründete die Entscheidung damit, dass es den Aufwand nicht wert sei, eine Bibliothek zu pflegen, die so gut wie gar nicht genutzt würde. Weiter meinte er, „Finally with Java 9, we started to actually remove old stuff from the JDK. Why shouldn’t we also throw away newer libraries that aren’t actually used much? And for those who really need something like it, there’s stil Joda-Time.“

Weiteres Vorgehen

Wie geht es nun weiter? Zunächst sollen alle Klassen der API als „deprecated“ markiert werden. Das wird laut JEP-472 bereits in Java Version 13 der Fall sein, die im Herbst 2019 erscheint. Endgültig entfernt werden sollen die Klassen in der nächsten LTS-Version 17, die ab Herbst 2021 verfügbar sein wird. So haben alle, die die neue API schon einsetzen, genug Zeit, ihre Anwendungen wieder auf die herkömmlichen Klassen zurück zu migrieren.

Ich selber finde es schade, da ich mich mittlerweile recht gut an die neue API gewöhnt habe :-(

Quellen:

jaxEnter-Artikel: Die Java Time API soll wieder weg!

JEP-472

Wenn wir mit neuer Besetzung in ein Projekt starten, stellen sich viele Fragen: welche Sprachen werden verwendet? Wie soll die Pipeline aussehen? Welche Tools verwenden wir?

Für die meisten Punkte findet sich schnell eine gemeinsame Lösung. Oft hat sich bereits ein Vorgehen oder Muster etabliert und kann so wiederverwendet werden – zum Beispiel beim Thema Codeformatierung. Doch mit unterschiedlichen Menschen kommen auch unterschiedliche Vorlieben. Viele Entwickler gewöhnen sich über lange Zeit an eine IDE und kennen sich damit sehr gut aus. Das Problem ist nur, dass selten alle die gleiche Entwicklungsumgebung nutzen möchten und hier muss eine Entscheidung getroffen werden – setzen alle das gleiche Werkzeug ein oder bleibt jeder bei dem, was er kennt? Hier ein paar Argumente für beide Seiten. (Hinweis: ich gehe hier nur auf die beiden verbreitetsten IDEs Eclipse und IntelliJ ein, die bei uns im Java-Umfeld Relevanz haben.)

Eine IDE für alle

Die einfachste Möglichkeit ist es, eine IDE als Standard festzulegen, die alle im Team dann nutzen (müssen). Daraus ergeben sich folgende Vorteile:

• Alle Einstellungen, von Codeformatierung über Templates bis zu Save Actions, müssen nur an einer Stelle gepflegt werden. Dazu kann man noch je nach IDE bequeme Verteilungsmechanismen nutzen, z.B. Oomph oder Yatta bei Eclipse oder das Settings Repository bei IntelliJ.
• Tiefergehendes Know-How im Umgang mit der Entwicklungsumgebung kann sich gut im Team verteilen – es gibt keine fragenden Gesichter, wenn jemand ein Feature erklärt, sondern eher den „Aha-Effekt“.
• Jeder findet sich beim Anderen zurecht – das hilft gerade bei Pair Programming Sessions. So vermeidet man den Klassiker: „Welche Tastenkombination ist das denn hier?“

Gemischte Welt

Der Gegenentwurf: jeder arbeitet mit dem, was er kennt und liebt. Da kommt folgendes in den Sinn:

• Wer sich nicht umstellen muss, kann effizient arbeiten. Bis die ganzen Menüwege, Tastenkürzel und Verhaltensweisen einer neuen IDE in Fleisch und Blut übergegangen sind, vergeht viel Zeit und die ist ja bekanntermaßen Geld. Hier gilt es also dringend abzuwägen, ob der erhöhte Abstimmungsaufwand bei gemischten IDEs das rechtfertigt.
• Es entsteht ein Know-How Austausch über den eigenen Tellerrand hinweg. Je nach Anwendungsfall bieten verschiedene Werkzeuge objektiv betrachtet eine bessere Unterstützung und da ist es gut, wenn man weiß, welches das richtige Werkzeug ist. Nicht umsonst gibt es das Sprichwort: „Wer nur einen Hammer hat, sieht in jedem Problem einen Nagel.“

Möglichkeiten zur Zusammenarbeit

Für beide Vorgehensweisen gibt es gute Gründe. In einem aktuellen Projekt haben wir den zweiten Weg gewählt und sind nach anfänglichen Startschwierigkeiten inzwischen ganz zufrieden. Wie bekommt man aber nun eine Zusammenarbeit einfach hin?

Doppelte Pflege

Die schlechteste Variante – jede Einstellung separat für die IDEs festlegen und pflegen. Die Abweichung voneinander ist quasi vorprogrammiert und man ärgert sich schnell über riesige Diffs im Pull Request.

EditorConfig

Das Projekt editorconfig.org hilft dabei, grundlegende Konventionen für den Code IDE-übergreifend einhalten zu können. Es wird von sehr vielen Editoren unterstützt (teils über Plugins, teils nativ) und bietet eine Konfiguration über .ini Dateien nach folgendem Muster:

Solange die gemeinsamen Regeln für den Code im Team nicht zu umfangreich sind, ist das eine tolle Sache. Sobald die Regeln aber über die unterstützten Features hinausgehen, scheitert der Ansatz leider.

Eclipse Settings in IntelliJ importieren

IntelliJ unterstützt seit Version 13 von Haus aus den Import von Eclipse Formatierungseinstellungen. Leider gab es hier recht schnell Ernüchterung bei uns, denn immer wieder fanden wir einzelne Punkte, die dann doch nicht übernommen wurden. Als Alternative nutzen wir inzwischen die beiden IntelliJ Plugins Eclipse Code Formatter und Save Actions. Dadurch konnten wir tatsächlich (fast!) alle unsere Regeln durch einen einfachen Import übernehmen. Eine 100% Lösung haben wir zwar immer noch nicht, aber dieser Weg funktioniert für uns ausreichend gut. Die festgelegten Regeln ändern sich ja im Laufe des Projekts eher wenig, daher ist uns vor allem wichtig, dass neue Entwickler sich schnell einrichten können.

Würde ich es im nächsten Projekt nun genauso tun? Ganz klar: es kommt drauf an – und zwar auf die Teammitglieder. Wenn es eine halbwegs gleiche Verteilung an Präferenzen gibt, dann ist das Mischmodell ein guter Weg, um früh effizient arbeiten zu können und die Erfahrung hat gezeigt, dass es funktioniert. Bei einem homogeneren Team mit wenigen Ausreißern würde ich wohl eine IDE vorgeben, um die dadurch entstehenden Vorteile für das Projekt mitnehmen zu können.

Das Internet der Dinge erhält Einzug in die Dusche an unserem Hauptsitz in Friedrichshafen. Mitarbeiter, die beispielsweise an unserer Fahrradaktion teilgenommen haben, möchten nach dem Sport die Dusche im Unternehmen benutzen. Kaum ist man zur Dusche gelaufen, muss man oftmals feststellen, dass die Dusche bereits belegt ist. Als Dienstleister für IoT-Services sehen wir hier Optimierungsbedarf.

Wir haben eine Hard- und Softwarelösung implementiert, um das Problem zu lösen. Unsere Mitarbeiter können nun über eine native Android App den Status der Dusche ermitteln. Bei Bedarf kann man sich über eine Push-Benachrichtigung auf dem Smartphone informieren lassen, sobald die Dusche wieder frei ist. Durch diese Lösung entfällt das lästige Warten vor der Dusche.

Entwicklung der Hardware

Zahlreiche Hersteller von smarten IoT-Devices setzen zur Vernetzung ihrer Produkte den Mikrocontroller „ESP8266“ des Herstellers Espressif ein. Hierbei handelt es sich um einen programmierbaren 32-Bit Mikrocontroller mit integriertem W-LAN und sehr geringem Stromverbrauch. Wir haben jenen Mikrocontroller mit einem analogen Fotowiderstand verbunden und im Vorraum der Dusche platziert. Auf diese Weise können wir ermitteln, ob das Licht in der Dusche eingeschaltet ist. Ist das Licht an, so ist die Dusche besetzt. Ist das Licht aus, so ist die Dusche frei.

Cloud Service

Zur Übertragung von Maschinendaten hat sich im IoT-Umfeld das Nachrichtenprotokoll MQTT etabliert. Jeder Statuswechsel des Lichts im Duschraum wird durch den Mikrocontroller über das MQTT-Protokoll an einen MQTT-Broker übermittelt. Jener Broker ist innerhalb eines Dockercontainers in der Cloud Computing Plattform Microsoft Azure gehostet.

Der MQTT-Broker hält die Daten aller Statuswechsel der Dusche vor. Die Android App verbindet sich mit dem MQTT-Broker und erhält in Folge alle Statuswechsel der Dusche. Bei Bedarf kann der Nutzer über die App eine Push-Benachrichtigung abonnieren. Er wird dann benachrichtigt, sobald die Dusche frei ist. Damit auch Mitarbeiter, die kein Android Smartphone besitzen, von der Lösung profitieren können, haben wir auf unserem OpenShift-Cluster eine Instanz der IoT-Plattform ThingWorx gehostet. ThingWorx verbindet sich mit dem MQTT-Broker und stellt den Status der Dusche im Webbrowser dar.

Seit dem Erscheinen von Java 11 ist schon wieder ein halbes Jahr vergangen. Gemäß dem neuen Releasezyklus bedeutet dies, dass das nächste Major Release vor der Tür steht. Am morgigen Dienstag, den 19.03.2019 ist es wieder soweit: Java 12 wird öffentlich verfügbar.Mehr