April April! (Entfernung der Time API ;-)

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

Neue Time API wird wieder aus Java entfernt

(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

Java 12 ist da!

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

The Value of Values

Bereits im Jahr 2012 hielt Rich Hickey, der Erfinder der Sprache Clojure, auf der jax San Francisco eine Keynote über den „Wert von Werten“. In dem sehr unterhaltsamen, noch immer aktuellen Vortrag erläutert er, wieso das Verwenden von immutable value objects eine gute Idee ist, und stellt die Frage, wieso wir immer noch PLOP praktizieren (was das ist erklärt er im Video ;-)Mehr

Java 11 kurz angetestet

Da diese Woche Java 11 erschienen ist (wie kürzlich hier berichtet), konnte ich es nicht lassen, ein klein wenig damit herumzuspielen.

Insbesondere war ich neugierig auf JEP-330, also der Möglichkeit, Java-Dateien direkt auszuführen zu können, ohne sie vorher kompilieren zu müssen. Voraussetzung ist, dass sich das komplette Programm innerhalb einer einzigen Java-Datei befindet.Mehr

Zip Slip – Gefahr beim Entpacken von Zipdateien mit Java

Das Security-Team von Snyk hat eine Schwachstelle entdeckt und veröffentlicht, die das Entpacken von Zipdateien mit Java betrifft. Die „Zip Slip“ getaufte Verwundbarkeit sowie Möglichkeiten zur Ausnutzung derselben sind auf der Seite Zip Slip Vulnerability beschrieben.

Betroffen sind vor allem Webanwendungen die es Nutzern erlauben, gepackte Dateien (zip, rar, jar, 7zip etc.) hochzuladenEntwickler solcher Anwendungen sollten unbedingt prüfen ob ihr Code betroffen ist!

Mehr