Ein Blog

Posts mit Tag "java"

How-to API nicht designen: String.split(String pattern) schneidet per default leere Strings am Ende des Ergebnis-Arrays weg (und nur da):

var arr = "a.b.".split("\\."); // ["a", "b"]

Dieses Verhalten alleine produziert schon Bugs (tatsächlich habe ich dadurch einen gefunden, der seit ~3 Jahren unbemerkt war).

Es wird aber noch besser! Wenn man das nicht will, also wenn man will, dass es sich so wie in jeder anderen Sprache verhält, muss man eine Überladung verwenden, die einen limit-Parameter hat. Warum limit? Na das ist die maximale Anzahl an Tokens für einen Match:

If n is non-positive then the pattern will be applied as many times as possible and the array can have any length. If n is zero [Anm. d. Red.: default] then the pattern will be applied as many times as possible, the array can have any length, and trailing empty strings will be discarded.

Das intuitive Verhalten wäre also:

var arr = "a.b.".split("\\.", -1); // ["a", "b", ""]

Java bekommt das Äquivalent zu Tagged Template Strings: String Template Expressions

Die Muttersprache der JVM entwickelt sich in eine andere Richtung als Kotlin. Kotlin hat dann bald viele Dinge redundant zu der nativen Java-Version.

Neulich hab ich was über ein neues Feature von Java 21 geschrieben.

Hier gibt es eine Liste an den neuen, interessanten Sachen in Java 21: The compact overview of JDK 21’s “frozen” feature list. Was mir dort in die Augen fällt:

  1. Valhalla is officially trying to bite on the topic of Nullability in Java

Valhalla ist der Projektname dafür, user-defined Value-Types in die JVM zu bringen, ähnlich zu denen in C# (Structs). Das zieht einen langen Rattenschwanz hinter sich her, darunter auch die Generics, die in Java mit Type-Erasure umgesetzt werden (in C# wird zur Laufzeit ein konkret anderer Typ instanziiert). Teil dieses Rattenschwanzes ist jetzt wohl auch Nullability.

Das wird jetzt nochmal viel interessanter, denn Nullability ist in Kotlin nochmal ganz anders gelöst. Ob wir am Ende einen super komplizierten Interop zwischen den Sprachen haben (was einer der Vorteile von Kotlin war) oder werden sie sich soweit voneinander entwickeln, dass sie inkompatibel werden?

Lesetipp: Why Checked Exceptions Failed Dazu gibt es noch einen Artikel mit Anders Hejlsberg (C#-Erfinder, wo es keine checked exceptions gibt): The Trouble with Checked Exceptions

Das finale Feature-Set von Java 23.

Hier eine Übersicht an Projekten, an denen Oracle in 2024 bei Java arbeitet.

Java 25 ist da.

Neu sind diese JEPs:

  • 470: PEM Encodings of Cryptographic Objects (Preview)
  • 502: Stable Values (Preview)
  • 503: Remove the 32-bit x86 Port
  • 505: Structured Concurrency (Fifth Preview)
  • 506: Scoped Values
  • 507: Primitive Types in Patterns, instanceof, and switch (Third Preview)
  • 508: Vector API (Tenth Incubator)
  • 509: JFR CPU-Time Profiling (Experimental)
  • 510: Key Derivation Function API
  • 511: Module Import Declarations
  • 512: Compact Source Files and Instance Main Methods
  • 513: Flexible Constructor Bodies
  • 514: Ahead-of-Time Command-Line Ergonomics
  • 515: Ahead-of-Time Method Profiling
  • 518: JFR Cooperative Sampling
  • 519: Compact Object Headers
  • 520: JFR Method Timing & Tracing
  • 521: Generational Shenandoah