{"id":25819,"date":"2021-12-28T13:34:00","date_gmt":"2021-12-28T12:34:00","guid":{"rendered":"https:\/\/www.happycoders.eu\/?p=25819"},"modified":"2025-06-11T21:32:19","modified_gmt":"2025-06-11T19:32:19","slug":"java-17-features","status":"publish","type":"post","link":"https:\/\/www.happycoders.eu\/de\/java\/java-17-features\/","title":{"rendered":"Java 17 Features (mit Beispielen)"},"content":{"rendered":"\n

Am 14. September 2021 war es endlich soweit: Nach den f\u00fcnf \"Zwischenversionen\" Java 12 bis 15, die jeweils nur f\u00fcr ein halbes Jahr maintained wurden, wurde das aktuelle Long-Term-Support (LTS) Release, Java 17, ver\u00f6ffentlicht.<\/p>\n\n\n\n

Oracle wird f\u00fcr Java 17 f\u00fcr mindestens f\u00fcnf Jahre, also bis September 2026, kostenlose Upgrades zur Verf\u00fcgung stellen \u2013 und bis September 2029 einen erweiterten, kostenpflichtigen Support.<\/p>\n\n\n\n

In Java 17 wurden 14 JDK Enhancement Proposals umgesetzt. Ich habe die \u00c4nderungen nach Relevanz f\u00fcr die t\u00e4gliche Programmierarbeit sortiert. Der Artikel beginnt mit Erweiterungen der Sprache und \u00c4nderungen am Modulsystem. Es folgen diverse Erweiterungen der JDK-Klassenbibliothek, Performance-Verbesserungen, neue Preview- und Incubator-Features, Deprecations und L\u00f6schungen und am Ende sonstige \u00c4nderungen, mit denen man in der t\u00e4glichen Arbeit eher selten in Kontakt kommt.<\/p>\n\n\n\n

Wie immer habe ich die englischen Bezeichnungen der JEPs und der sonstigen \u00c4nderungen verwendet. Eine \u00dcbersetzung ins Deutsche w\u00fcrde hier keinen Mehrwert bringen. <\/p>\n\n\n\n\n\n

Sealed Classes<\/h2>\n\n\n\n

Die gro\u00dfe Neuerung in Java 17 (neben dem Long-Term-Support) sind versiegelte Klassen und Interfaces.<\/p>\n\n\n\n

Was versiegelte Klassen sind, wie sie genau funktionieren und warum wir sie brauchen, erkl\u00e4re ich aufgrund des Umfangs des Themas in einem separaten Artikel: Sealed Classes in Java<\/a><\/p>\n\n\n\n

(Sealed Classes wurden erstmals in Java 15<\/a> als Preview-Feature vorgestellt. In Java 16<\/a> wurden drei kleine \u00c4nderungen ver\u00f6ffentlicht. Mit dem JDK Enhancement Proposal 409<\/a> werden Sealed Classes in Java 17 ohne weitere \u00c4nderungen als produktionsreif deklariert.)<\/em><\/p>\n\n\n\n

Strongly Encapsulate JDK Internals<\/h2>\n\n\n\n

In Java 9 wurde das Modulsystem (Project Jigsaw<\/a>) eingef\u00fchrt, insbesondere um Code besser modularisieren zu k\u00f6nnen und um die Sicherheit der Java-Plattform zu erh\u00f6hen.<\/p>\n\n\n\n

Vor Java 16: Relaxed Strong Encapsulation<\/h3>\n\n\n\n

Bis Java 16 hatte dies nur wenige Auswirkungen auf existierenden Code, da die JDK-Entwickler f\u00fcr eine \u00dcbergangszeit den Modus \"Relaxed Strong Encapsulation\" bereitgestellt haben. <\/p>\n\n\n\n

Dieser erlaubte es ohne Konfigurations\u00e4nderung per Deep Reflection auf nicht-\u00f6ffentliche Klassen und Methoden von Paketen der JDK-Klassenbibliothek, die schon vor Java 9 existierten, zuzugreifen.<\/p>\n\n\n\n

Das folgende Beispiel extrahiert die Bytes eines String, indem es dessen privates Feld value<\/code> ausliest:<\/p>\n\n\n

public<\/span> class<\/span> EncapsulationTest<\/span> <\/span>{\n  public<\/span> static<\/span> void<\/span> main<\/span>(String[] args)<\/span> throws<\/span> ReflectiveOperationException <\/span>{\n    byte<\/span>[] value = getValue(\"Happy Coding!\"<\/span>);\n    System.out.println(Arrays.toString(value));\n  }\n\n  private<\/span> static<\/span> byte<\/span>[] getValue(String string) throws<\/span> ReflectiveOperationException {\n    Field VALUE = String.class<\/span>.getDeclaredField<\/span>(\"value<\/span>\")<\/span>;\n    VALUE.setAccessible(true<\/span>);\n    return<\/span> (byte<\/span>[]) VALUE.get(string);\n  }\n}\n<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
Wenn wir dieses Programm mit Java 9 bis 15 aufrufen, erhalten wir folgende Ausgabe:<\/p>\n\n\n
$ java EncapsulationTest.java\nWARNING: An illegal reflective access operation has occurred\nWARNING: Illegal reflective access by EncapsulationTest (file:\/...\/EncapsulationTest.java) to field java.lang.String.value\nWARNING: Please consider reporting this to the maintainers of EncapsulationTest\nWARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations\nWARNING: All illegal access operations will be denied in a future release\n[72, 97, 112, 112, 121, 32, 67, 111, 100, 105, 110, 103, 33]\n<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n
Wir sehen zwar einige Warnungen, bekommen dann aber die gew\u00fcnschten Bytes angezeigt.<\/p>\n\n\n\n
Deep Reflection auf neue<\/em> Pakete hingegen war standardm\u00e4\u00dfig nicht erlaubt und musste seit der Einf\u00fchrung des Modulsystems per \"--add-opens\" auf der Kommandozeile explizit erlaubt werden.<\/p>\n\n\n\n
Das folgende Beispiel versucht die Klasse ConstantDescs<\/code> aus dem in Java 12 (also nach der Einf\u00fchrung des Modulsystems) hinzugekommenen Paket java.lang.constant<\/code> \u00fcber deren privaten Constructor zu instanziieren:<\/p>\n\n\n
Constructor<ConstantDescs> constructor = ConstantDescs.class<\/span>.getDeclaredConstructor<\/span>()<\/span>;\nconstructor.setAccessible(true<\/span>);\nConstantDescs constantDescs = constructor.newInstance();\n<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
Das Programm bricht mit folgender Fehlermeldung ab:<\/p>\n\n\n
$ java ConstantDescsTest.java\nException in thread \"main\" java.lang.reflect.InaccessibleObjectException: Unable to make private java.lang.constant.ConstantDescs() accessible: module java.base does not \"opens java.lang.constant\" to unnamed module @6c3f5566\n        at java.base\/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:361)\n        at java.base\/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:301)\n        at java.base\/java.lang.reflect.Constructor.checkCanSetAccessible(Constructor.java:189)\n        at java.base\/java.lang.reflect.Constructor.setAccessible(Constructor.java:182)\n        at ConstantDescsTest.main(ConstantDescsTest.java:7)\n<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n
Um das Programm lauff\u00e4hig zu machen, m\u00fcssen wir per --add-opens<\/code> das neue Paket f\u00fcr Deep Reflection \u00f6ffnen:<\/p>\n\n\n
$ java --add-opens java.base\/java.lang.constant=ALL-UNNAMED ConstantDescsTest.java\n<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n
Der Code l\u00e4uft dann fehlerfrei und ohne Warnungen durch.<\/p>\n\n\n\n
Seit Java 16: Standardm\u00e4\u00dfig Strong Encapsulation + Optional Relaxed Strong Encapsulation<\/h3>\n\n\n\n
In Java 16<\/a> wurde der Standardmodus von \"Relaxed Strong Encapsulation\" auf \"Strong Encapsulation\" ge\u00e4ndert. Seither musste auch der Zugriff auf Pre-Java-9-Pakete explizit erlaubt werden.<\/p>\n\n\n\n
Wenn wir das erste Beispiel unter Java 16 ausf\u00fchren, ohne den Zugriff explizit zu erlauben, erhalten wir folgende Fehlermeldung:<\/p>\n\n\n
$ java EncapsulationTest.java\nException in thread \"main\" java.lang.reflect.InaccessibleObjectException: Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not \"opens java.lang\" to unnamed module @62fdb4a6\n        at java.base\/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)\n        at java.base\/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)\n        at java.base\/java.lang.reflect.Field.checkCanSetAccessible(Field.java:177)\n        at java.base\/java.lang.reflect.Field.setAccessible(Field.java:171)\n        at EncapsulationTest.getValue(EncapsulationTest.java:12)\n        at EncapsulationTest.main(EncapsulationTest.java:6)\n<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n
Java 16 bot allerdings noch einen Workaround: Per VM-Option --illegal-access=permit<\/code> konnte auf \"Relaxed Strong Encapsulation\" zur\u00fcckgeschaltet werden:<\/p>\n\n\n
$ java --illegal-access=permit EncapsulationTest.java\nJava HotSpot(TM) 64-Bit Server VM warning: Option --illegal-access is deprecated and will be removed in a future release.\nWARNING: An illegal reflective access operation has occurred\nWARNING: Illegal reflective access by EncapsulationTest (file:\/...\/EncapsulationTest.java) to field java.lang.String.value\nWARNING: Please consider reporting this to the maintainers of EncapsulationTest\nWARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations\nWARNING: All illegal access operations will be denied in a future release\n[72, 97, 112, 112, 121, 32, 67, 111, 100, 105, 110, 103, 33]\n<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n
Seit Java 17: Ausschlie\u00dflich Strong Encapsulation<\/h3>\n\n\n\n
Per JDK Enhancement Proposal 403<\/a> wird diese M\u00f6glichkeit ab Java 17 entfernt. Die VM-Option --illegal-access<\/code> wurde mit einer Warnung versehen, und der Zugriff auf String.value<\/code> ist standardm\u00e4\u00dfig nicht mehr m\u00f6glich:<\/p>\n\n\n
java --illegal-access=permit EncapsulationTest.java\nOpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit; support was removed in 17.0\nException in thread \"main\" java.lang.reflect.InaccessibleObjectException: Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not \"opens java.lang\" to unnamed module @3e77a1ed\n        at java.base\/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)\n        at java.base\/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)\n        at java.base\/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)\n        at java.base\/java.lang.reflect.Field.setAccessible(Field.java:172)\n        at EncapsulationTest.getValue(EncapsulationTest.java:12)\n        at EncapsulationTest.main(EncapsulationTest.java:6)\n<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n
Wer ab Java 17 Deep Reflection einsetzen will, muss dies nun explizit mit --add-opens<\/code> erlauben:<\/p>\n\n\n
$ java --add-opens java.base\/java.lang=ALL-UNNAMED EncapsulationTest.java\n[72, 97, 112, 112, 121, 32, 67, 111, 100, 105, 110, 103, 33]\n<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n
Das Programm l\u00e4uft, und wir sehen keine Warnungen mehr \u2013 die lange \u00dcbergangsphase seit Java 9 ist damit abgeschlossen.<\/p>\n\n\n\n
Add java.time.InstantSource<\/h2>\n\n\n\n
Die Klasse java.time.Clock<\/code> ist \u00e4u\u00dferst n\u00fctzlich, um Tests zu schreiben, die zeitabh\u00e4ngige Funktionalit\u00e4t \u00fcberpr\u00fcfen.<\/p>\n\n\n\n
Wenn Clock<\/code> z. B. per Dependency Injection in die Anwendungsklassen injiziert wird, kann man diese in Tests mocken oder durch Clock.fixed()<\/code> eine feste Uhrzeit f\u00fcr die Testausf\u00fchrung festlegen.<\/p>\n\n\n\n
Da Clock<\/code> die Methode getZone()<\/code> bereitstellt, muss man sich immer Gedanken dar\u00fcber machen, mit welcher konkreten Zeitzone man ein Clock<\/code>-Objekt instanziiert.<\/p>\n\n\n\n
Um alternative, Zeitzonen-unabh\u00e4ngige Zeitquellen zu erm\u00f6glichen, wurde in Java 17 das Interface java.time.InstantSource<\/code> aus Clock<\/code> extrahiert, welches zum Abfragen der Zeit nur noch die Methoden instant()<\/code> und millis()<\/code> bereitstellt, wobei millis()<\/code> bereits als Default-Methode implementiert ist.<\/p>\n\n\n\n
Die Timer<\/code>-Klasse im folgenden Beispiel nutzt InstantSource<\/code>, um die Start- und Endzeit der Ausf\u00fchrung eines Runnable<\/code> festzustellen und daraus die Dauer der Ausf\u00fchrung zu berechnen:<\/p>\n\n\n
public<\/span> class<\/span> Timer<\/span> <\/span>{\n  private<\/span> final<\/span> InstantSource instantSource;\n\n  public<\/span> Timer<\/span>(InstantSource instantSource)<\/span> <\/span>{\n    this<\/span>.instantSource = instantSource;\n  }\n\n  public<\/span> Duration measure<\/span>(Runnable runnable)<\/span> <\/span>{\n    Instant start = instantSource.instant();\n    runnable.run();\n    Instant end = instantSource.instant();\n    return<\/span> Duration.between(start, end);\n  }\n}\n<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
In Produktion k\u00f6nnen wir Timer<\/code> mit der System-Uhr instanziieren (wobei wir uns mangels alternativer InstantSource<\/code>-Implementierungen Gedanken um die Zeitzone machen m\u00fcssen \u2013 wir nehmen die Standardzeitzone des Systems):<\/p>\n\n\n
Timer timer = new<\/span> Timer(Clock.systemDefaultZone());<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
Testen k\u00f6nnen wir die measure()<\/code>-Methode, indem wir InstantSource<\/code> mocken, deren instant()<\/code>-Methode zwei feste Werte zur\u00fcckgeben lassen und den R\u00fcckgabewert von measure()<\/code> mit der Differenz dieser Werte vergleichen:<\/p>\n\n\n
@Test<\/span>\nvoid<\/span> shouldReturnDurationBetweenStartAndEnd<\/span>()<\/span> <\/span>{\n  InstantSource instantSource = mock(InstantSource.class<\/span>)<\/span>;\n  when(instantSource.instant())\n      .thenReturn(Instant.ofEpochMilli(1_640_033_566_000L<\/span>))\n      .thenReturn(Instant.ofEpochMilli(1_640_033_567_750L<\/span>));\n\n  Timer timer = new<\/span> Timer(instantSource);\n  Duration duration = timer.measure(() -> {});\n\n  assertThat(duration, is(Duration.ofMillis(1_750<\/span>)));\n}<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
F\u00fcr diese Erweiterung gibt es kein JDK Enhancement Proposal.<\/em><\/p>\n\n\n\n
Hex Formatting and Parsing Utility<\/h2>\n\n\n\n
Um hexadezimale Zahlen auszugeben, konnten wir bisher die toHexString()<\/code>-Methode der Klassen Integer<\/code>, Long<\/code>, Float<\/code> und Double<\/code> verwenden \u2013 oder String.format()<\/code> einsetzen. Der folgende Code zeigt ein paar Beispiele:<\/p>\n\n\n
System.out.println(Integer.toHexString(1_000<\/span>));\nSystem.out.println(Long.toHexString(100_000_000_000L<\/span>));\nSystem.out.println(Float.toHexString(3.14F<\/span>));\nSystem.out.println(Double.toHexString(3.14159265359<\/span>));\n\nSystem.out.println(\n    \"%x - %x - %a - %a\"<\/span>.formatted(1_000<\/span>, 100_000_000_000L<\/span>, 3.14F<\/span>, 3.14159265359<\/span>));<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
Der Code f\u00fchrt zu folgender Ausgabe:<\/p>\n\n\n
3e8\n174876e800\n0x1.91eb86p1\n0x1.921fb54442eeap1\n3e8 - 174876e800 - 0x1.91eb86p1 - 0x1.921fb54442eeap1<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n
Parsen konnten wir hexadezimale Zahlen mit den jeweiligen Pendants:<\/p>\n\n\n
Integer.parseInt(\"3e8\"<\/span>, 16<\/span>);\nLong.parseLong(\"174876e800\"<\/span>, 16<\/span>);\nFloat.parseFloat(\"0x1.91eb86p1\"<\/span>);\nDouble.parseDouble(\"0x1.921fb54442eeap1\"<\/span>);\n<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
Java 17 stellt die neue Klasse java.util.HexFormat<\/code> zur Verf\u00fcgung, mit der Darstellen und Parsen hexadezimaler Zahlen \u00fcber eine einheitliche API abgebildet wird. HexFormat<\/code> unterst\u00fctzt dabei alle primitiven Ganzzahlen (int<\/code>, byte<\/code>, char<\/code>, long<\/code>, short<\/code>) sowie byte<\/code>-Arrays \u2013 allerdings keine Flie\u00dfkommazahlen. <\/p>\n\n\n\n
Hier ein Beispiel f\u00fcr die Umwandlung in hexadezimale Zahlen:<\/p>\n\n\n
HexFormat hexFormat = HexFormat.of();\n\nSystem.out.println(hexFormat.toHexDigits('A'<\/span>));\nSystem.out.println(hexFormat.toHexDigits((byte<\/span>) 10<\/span>));\nSystem.out.println(hexFormat.toHexDigits((short<\/span>) 1_000<\/span>));\nSystem.out.println(hexFormat.toHexDigits(1_000_000<\/span>));\nSystem.out.println(hexFormat.toHexDigits(100_000_000_000L<\/span>));\nSystem.out.println(hexFormat.formatHex(new<\/span> byte<\/span>[] {1<\/span>, 2<\/span>, 3<\/span>, 60<\/span>, 126<\/span>, -1<\/span>}));<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
Die Ausgabe lautet:<\/p>\n\n\n
0041\n0a\n03e8\n000f4240\n000000174876e800\n0102033c7eff<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n
Es f\u00e4llt auf, dass die Ausgabe jeweils mit vorangestellten Nullen erfolgt.<\/p>\n\n\n\n
Die Darstellung k\u00f6nnen wir z. B. wie folgt anpassen:<\/p>\n\n\n
HexFormat hexFormat = HexFormat.ofDelimiter(\" \"<\/span>).withPrefix(\"0x\"<\/span>).withUpperCase();\n<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
    \n
  • ofDelimiter()<\/code> legt ein Trennzeichen f\u00fcr die Formatierung von Byte-Arrays fest.<\/li>\n\n\n\n
  • withPrefix()<\/code> definiert ein Prefix \u2013 allerdings nur f\u00fcr Byte-Arrays!<\/li>\n\n\n\n
  • withUpperCase()<\/code> schaltet die Ausgabe auf Gro\u00dfbuchstaben um.<\/li>\n<\/ul>\n\n\n\n
    Die Ausgabe lautet nun:<\/p>\n\n\n
    0041\n0A\n03E8\n000F4240\n000000174876E800\n0x01 0x02 0x03 0x3C 0x7E 0xFF<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n
    Die vorangestellten Nullen lassen sich nicht entfernen.<\/p>\n\n\n\n
    Ganzzahlen k\u00f6nnen wir wie folgt parsen:<\/p>\n\n\n
    int<\/span> i = HexFormat.fromHexDigits(\"F4240\"<\/span>);\nlong<\/span> l = HexFormat.fromHexDigitsToLong(\"174876E800\"<\/span>);\n<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
    Entsprechende Methoden f\u00fcr char<\/code>, byte<\/code> und short<\/code> existieren nicht.<\/p>\n\n\n\n
    Byte-Arrays parsen k\u00f6nnen wir z. B. wie folgt:<\/p>\n\n\n
    HexFormat hexFormat = HexFormat.ofDelimiter(\" \"<\/span>).withPrefix(\"0x\"<\/span>).withUpperCase();\nbyte<\/span>[] bytes = hexFormat.parseHex(\"0x01 0x02 0x03 0x3C 0x7E 0xFF\"<\/span>);\n<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
    Es gibt noch weitere Methoden, um z. B. nur einen Teilstring zu parsen. Eine vollst\u00e4ndige Dokumentation findest du im HexFormat-JavaDoc<\/a>.<\/p>\n\n\n\n
    F\u00fcr diese Erweiterung gibt es kein JDK Enhancement Proposal.<\/em><\/p>\n\n\n\n
    Context-Specific Deserialization Filters<\/h2>\n\n\n\n
    Deserialisierung von Objekten stellt ein erhebliches Sicherheitsrisiko dar. B\u00f6swillige Angreifer k\u00f6nnen \u00fcber den zu deserialisierenden Datenstrom Objekte konstruieren, \u00fcber die sie letztendlich beliebigen Code in beliebigen (auf dem Classpath verf\u00fcgbaren) Klassen ausf\u00fchren k\u00f6nnen.<\/p>\n\n\n\n
    In Java 9 wurden erstmals Deserialisierungsfilter eingef\u00fchrt, d. h. die M\u00f6glichkeit festzulegen, welche Klassen deserialisiert werden d\u00fcrfen (bzw. welche nicht).<\/p>\n\n\n\n
    Bisher gab es zwei M\u00f6glichkeiten Deserialisierungsfilter zu definieren:<\/p>\n\n\n\n
      \n
    • per ObjectInputStream.setObjectInputFilter()<\/code> f\u00fcr jede Deserialisierung separat,<\/li>\n\n\n\n
    • systemweit einheitlich per System Property jdk.serialFilter<\/code> oder per gleichnamiger Security Property in der Datei conf\/security\/java.properties<\/code>.<\/li>\n<\/ul>\n\n\n\n
      Bei komplexen Anwendungen, insbesondere bei solchen mit Drittanbieter-Bibliotheken, welche ebenfalls Deserialisierungs-Code enthalten, sind diese Varianten nicht zufriedenstellend. So kann bspw. die Deserialisierung in Drittanbieter-Code nicht per ObjectInputStream.setObjectInputFilter()<\/code> konfiguriert werden (es sei denn, man \u00e4ndert deren Quellcode), sondern nur global.<\/p>\n\n\n\n
      JDK Enhancement Proposal 415<\/a> macht es ab Java 17 m\u00f6glich, Deserialisierungsfilter kontextspezifisch festzulegen, z. B. f\u00fcr einen bestimmten Thread oder basierend auf dem Call Stack f\u00fcr eine bestimmte Klasse, ein Modul, oder eine Drittanbieter-Bibliothek.<\/p>\n\n\n\n
      Die Konfiguration der Filter ist nicht ganz einfach und w\u00fcrde den Rahmen dieses Artikels sprengen. Details findest du im oben verlinkten JEP.<\/p>\n\n\n\n
      JDK Flight Recorder Event for Deserialization<\/h3>\n\n\n\n
      Ab Java 17 ist es au\u00dferdem m\u00f6glich die Deserialisierung von Objekten \u00fcber den JDK Flight Recorder (JFR) zu \u00fcberwachen.<\/p>\n\n\n\n
      Deserialisierungsevents sind per Default deaktiviert und m\u00fcssen \u00fcber den Event-Bezeichner jdk.Deserialization<\/code> in der JFR-Konfigurationsdatei aktiviert werden (ein Beispiel dazu findest du im unten verlinkten Artikel).<\/p>\n\n\n\n
      Wenn ein Deserialisierungsfilter aktiviert ist, enth\u00e4lt das JFR-Event die Angabe dar\u00fcber, ob die Deserialisierung ausgef\u00fchrt oder abgewiesen wurde.<\/p>\n\n\n\n
      Detailliertere Informationen und ein Beispiel findest du im Artikel \"Monitoring Deserialization to Improve Application Security<\/a>\".<\/p>\n\n\n\n
      Die Flight Recorder Events f\u00fcr die Deserialisierung sind nicht Teil des o. g. JDK Enhancement Proposals; auch existiert f\u00fcr sie kein separater JEP.<\/em><\/p>\n\n\n