Java 18, ver\u00f6ffentlicht am 22. M\u00e4rz 2022, ist das erste \"Zwischen-Release\" nach dem letzten Long-Term-Support (LTS)-Release, Java 17.<\/p>\n\n\n\n
Der Umfang an Erweiterungen in Java 18 ist mit neun umgesetzten JEPs gegen\u00fcber den vorherigen Releases deutlich zur\u00fcckgegangen. Nach dem LTS-Release Java 17 sei den JDK-Entwicklern eine kleine Verschnaufspause geg\u00f6nnt ;-)<\/p>\n\n\n\n
Wie immer verwende ich die englischen Bezeichnungen der JEPs. Diese auf deutsch zu \u00fcbersetzen w\u00fcrde eher verwirren als einen Mehrwert zu bringen.<\/p>\n\n\n\n\n\n
Seit langem m\u00fcssen wir Java-Entwicklerinnen und -Entwickler mit der Tatsache umgehen, dass der Java-Standardzeichensatz je nach Betriebssystem und Spracheinstellungen unterschiedlich ist.<\/p>\n\n\n\n
Das \u00e4ndert sich mit Java 18 :-)<\/p>\n\n\n\n
Der Java-Standardzeichensatz bestimmt bei zahlreichen Methoden der JDK-Klassenbibliothek, wie Zeichenfolgen in Bytes umgewandelt werden und umgekehrt (z. B. beim Schreiben und Lesen einer Textdatei). Dazu geh\u00f6ren z. B.: <\/p>\n\n\n\n
FileReader<\/code>, FileWriter<\/code>, InputStreamReader<\/code>, OutputStreamWriter<\/code>, <\/li>\n\n\n\n- die Konstruktoren von
Formatter<\/code> und Scanner<\/code>,<\/li>\n\n\n\n- die statischen Methoden
URLEncoder.encode()<\/code> und URLDecoder.decode()<\/code>.<\/li>\n<\/ul>\n\n\n\nDas kann zu unvorhergesehenem Verhalten f\u00fchren, wenn eine Anwendung in einer Umgebung entwickelt und getestet \u2013 und dann in einer anderen Umgebung (in der sich Java f\u00fcr einen anderen Standardzeichensatz entscheidet) ausgef\u00fchrt wird.<\/p>\n\n\n\n
F\u00fchren wir z. B. den folgenden Code unter Linux oder macOS aus (der japanische Text hei\u00dft laut Google Translate \"Happy Coding!\"):<\/p>\n\n\n
try<\/span> (FileWriter fw = new<\/span> FileWriter(\"happy-coding.txt\"<\/span>);\n BufferedWriter bw = new<\/span> BufferedWriter(fw)) {\n bw.write(\"\u30cf\u30c3\u30d4\u30fc\u30b3\u30fc\u30c7\u30a3\u30f3\u30b0\uff01\"<\/span>);\n}<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n... und laden diese Datei dann mit folgendem Code unter Windows:<\/p>\n\n\n
try<\/span> (FileReader fr = new<\/span> FileReader(\"happy-coding.txt\"<\/span>);\n BufferedReader br = new<\/span> BufferedReader(fr)) {\n String line = br.readLine();\n System.out.println(line);\n}<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\nDann wird folgendes angezeigt:<\/p>\n\n\n
\u00e3\u0192?\u00e3\u0192\u0192\u00e3\u0192\u201d\u00e3\u0192\u00bc\u00e3\u201a\u00b3\u00e3\u0192\u00bc\u00e3\u0192\u2021\u00e3\u201a\u00a3\u00e3\u0192\u00b3\u00e3\u201a\u00b0\u00ef\u00bc?<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\nDas liegt daran, dass Linux und macOS die Datei im UTF-8-Format speichern und Windows sie im Windows-1252-Format versucht zu lesen.<\/p>\n\n\n\n
Das Problem \u2013 Stufe zwei<\/h4>\n\n\n\n
Noch chaotischer wird es dadurch, dass neuere Methoden der Klassenbibliothek den Standardzeichensatz nicht<\/em> ber\u00fccksichtigen, sondern bei fehlender Angabe eines Zeichensatzes grunds\u00e4tzlich UTF-8 verwenden. Zu diesen Methoden geh\u00f6ren z. B. Files.writeString()<\/code>, Files.readString()<\/code>, Files.newBufferedWriter()<\/code> und Files.newBufferedReader()<\/code>.<\/p>\n\n\n\nStarten wir einmal das folgende Programm, das den japanischen Text per FileWriter<\/code> schreibt und direkt danach per Files.readString()<\/code> wieder einliest:<\/p>\n\n\ntry<\/span> (FileWriter fw = new<\/span> FileWriter(\"happy-coding.txt\"<\/span>);\n BufferedWriter bw = new<\/span> BufferedWriter(fw)) {\n bw.write(\"\u30cf\u30c3\u30d4\u30fc\u30b3\u30fc\u30c7\u30a3\u30f3\u30b0\uff01\"<\/span>);\n}\n\nString text = Files.readString(Path.of(\"happy-coding.txt\"<\/span>));\nSystem.out.println(text);<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\nUnter Linux\/macOS wird der korrekte japanische Text angezeigt. Unter Windows hingegen nur Fragezeichen:<\/p>\n\n\n
???????????<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\nDas liegt daran, dass der FileWriter<\/code> unter Windows die Datei mit dem Java-Standardzeichensatz Windows-1252 schreibt, Files.readString()<\/code> die Datei aber als UTF-8 \u2013 unabh\u00e4ngig vom Standardzeichensatz \u2013 wieder einliest.<\/p>\n\n\n\nBisherige L\u00f6sungsm\u00f6glichkeiten<\/h4>\n\n\n\n
Um eine Anwendung gegen solche Fehler zu wappnen, gab es bisher zwei M\u00f6glichkeiten:<\/p>\n\n\n\n
\n- Angabe des Zeichensatzes beim Aufruf aller Methoden, welche Zeichenfolgen in Bytes umwandeln und umgekehrt.<\/li>\n\n\n\n
- Setzen des Standardzeichensatzes per System Property \"file.encoding\".<\/li>\n<\/ol>\n\n\n\n
Die erste M\u00f6glichkeit f\u00fchrt zu einer Menge Code Duplication und ist somit unsch\u00f6n und fehleranf\u00e4llig:<\/p>\n\n\n
FileWriter fw = new<\/span> FileWriter(\"happy-coding.txt\"<\/span>, StandardCharsets.UTF_8);\n\/\/ ...<\/span>\nFileReader fr = new<\/span> FileReader(\"happy-coding.txt\"<\/span>, StandardCharsets.UTF_8);\n\/\/ ...<\/span>\nFiles.readString(Path.of(\"happy-coding.txt\"<\/span>), StandardCharsets.UTF_8);<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\nDie Angabe der Zeichensatz-Parameter verhindert au\u00dferdem, dass wir Methodenreferenzen verwenden k\u00f6nnen, wie in folgendem Beispiel:<\/p>\n\n\n
Stream<String> encodedParams = ...\nStream<String> decodedParams = encodedParams.map(URLDecoder::decode);\n<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\nStattdessen m\u00fcssten wir schreiben:<\/p>\n\n\n
Stream<String> encodedParams = ...\nStream<String> decodedParams =\n encodedParams.map(s -> URLDecoder.decode(s, StandardCharsets.UTF_8));\n<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\nDie zweite M\u00f6glichkeit (System Property \"file.encoding\") war zum einen bis einschlie\u00dflich Java 17 nicht offiziell dokumentiert (s. Dokumentation der System Properties<\/a>).<\/p>\n\n\n\nZum anderen wird, wie oben erl\u00e4utert, der so festgelegte Zeichensatz nicht f\u00fcr alle API-Methoden verwendet. Die Variante ist also ebenfalls fehleranf\u00e4llig, wie wir an dem Beispiel von oben zeigen k\u00f6nnen:<\/p>\n\n\n
public<\/span> class<\/span> Jep400Example<\/span> <\/span>{\n public<\/span> static<\/span> void<\/span> main<\/span>(String[] args)<\/span> throws<\/span> IOException <\/span>{\n try<\/span> (FileWriter fw = new<\/span> FileWriter(\"happy-coding.txt\"<\/span>);\n BufferedWriter bw = new<\/span> BufferedWriter(fw)) {\n bw.write(\"\u30cf\u30c3\u30d4\u30fc\u30b3\u30fc\u30c7\u30a3\u30f3\u30b0\uff01\"<\/span>);\n }\n\n String text = Files.readString(Path.of(\"happy-coding.txt\"<\/span>));\n System.out.println(text);\n }\n}<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\nLassen wir das Programm einmal mit Standard-Encoding US-ASCII laufen:<\/p>\n\n\n
$ java -Dfile.encoding=US-ASCII Jep400Example.java\n?????????????????????????????????<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\nDabei kommt nur M\u00fcll heraus, da zwar FileWriter<\/code> das eingestellte Standard-Encoding ber\u00fccksichtigt, Files.readString()<\/code> es allerdings ignoriert und immer UTF-8 verwendet. Diese Variante funktioniert also nur dann zuverl\u00e4ssig, wenn einheitlich UTF-8 eingesetzt wird:<\/p>\n\n\n$ java -Dfile.encoding=UTF-8 Jep400Example.java\n\u30cf\u30c3\u30d4\u30fc\u30b3\u30fc\u30c7\u30a3\u30f3\u30b0\uff01<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\nJEP 400 als Retter in der Not<\/h4>\n\n\n\n
Per JDK Enhancement Proposal 400<\/a> werden ab Java 18 die genannten Probleme \u2013 zumindest gr\u00f6\u00dftenteils \u2013 der Vergangenheit angeh\u00f6ren.<\/p>\n\n\n\nDas Standard-Encoding wird auf allen Betriebssystemen und unabh\u00e4ngig von den Gebiets- und Spracheinstellungen immer UTF-8 sein.<\/p>\n\n\n\n
Au\u00dferdem wird die System Property \"file.encoding\" dokumentiert sein, womit wir sie legitim einsetzen k\u00f6nnen. Das sollten wir allerdings mit Bedacht tun. Denn an der Tatsache, dass die Files<\/code>-Methoden das eingestellte Standard-Encoding ignorieren, wird sich auch durch JEP 400 nichts \u00e4ndern. <\/p>\n\n\n\nLaut Dokumentation<\/a> sollten ohnehin nur die Werte \"UTF-8\" und \"COMPAT\" verwendet werden, wobei UTF-8 f\u00fcr einheitliche Codierung sorgt und COMPAT das Verhalten von vor Java 18 simuliert. Alle anderen Werte f\u00fchren zu unspezifiziertem Verhalten.<\/p>\n\n\n\nGut m\u00f6glich, dass \"file.encoding\" in Zukunft \"deprecated\" und sp\u00e4ter komplett entfernt wird, um die verbleibende potentielle Fehlerquelle (Methoden die das Standard-Encoding respektieren vs. solche, die es nicht tun) zu eliminieren.<\/p>\n\n\n\n
Im besten Fall setzen wir \"-Dfile.encoding\" immer auf UTF-8 oder lassen es komplett weg.<\/p>\n\n\n\n
Auslesen der Encodings zur Laufzeit<\/h4>\n\n\n\n