Inselraus: parse*(…)- und print*()-Methoden in DatatypeConverter für Hex-Ausgaben

Das javax.xml.bind-Paket bietet eine Klasse DatatypeConverter, die eigentlich für die Abbildung von XML-Typen auf Java-Typen gedacht ist, doch auch so einige nützliche Methoden bereitstellt. Wir finden in der Klasse statische parse*(String)-Methoden und print*(…)-Methoden: Die ersten konvertieren einen String in diverse Datentypen – etwa short parseShort(String) –, und die zweiten formatieren einen bestimmten Datentyp in einen String – etwa String printShort(short). Für die meisten Methoden gibt es mit String.valueOf(…) und den parse*(…)/toString(…)-Methoden in den Wrapper-Klassen bessere Alternativen, und die Umwandlung von Datumswerten und Fließkommazahlen ist nicht lokalisiert, doch hervorzuheben sind folgende zwei Methoden:

final class javax.xml.bind.DatatypeConverter

  • staticbyte[]parseHexBinary(StringlexicalXSDHexBinary)
  • staticStringprintHexBinary(byte[]val)

Mit diesen statischen Methoden können leicht Byte-Arrays in die String-Repräsentationen hexadezimal konvertiert werden. Das ist nötig, wenn etwa Bytes in einer Text-Konfigurationsdatei abgelegt werden sollen. DatatypeConverter bietet auch Methoden für eine Base64-Kodierung, allerdings sind die geschachtelten Klassen in java.util.Base64 üblicher.

Beispiel:

Konvertiere ein Byte-Array in eine String-Repräsentation, einmal im klassischen Hex-Format, einmal in Base64-Kodierung:

byte[] bytes = { 1, 2, 3, (byte) 254, (byte) 255 };
String s1 = DatatypeConverter.printHexBinary( bytes );
String s2 = DatatypeConverter.printBase64Binary( bytes );
System.out.println( s1 ); // 010203FEFF
System.out.println( s2 ); // AQID/v8=
// Arrays.equals( bytes, DatatypeConverter.parseHexBinary( s1 ) ) == true
// Arrays.equals( bytes, DatatypeConverter.parseBase64Binary( s2 ) ) == true

Inselupdate: strictfp verschwindet in Java 17

Zwischen Java 1.2 und Java 16 unterstützte der Java-Compiler das Schlüsselwort strictfp. Die Unterscheidung sollte es der Laufzeitumgebung erlauben, nicht strikt nach der IEEE-754-Spezifikation zu arbeiten und damit schneller auf der lokalen Hardware Java-Programme auszuführen. Doch seit 20 Jahren unterstützen alle Prozessoren IEEE-754, und die Unterscheidung ist irrelevant geworden – alle von der JVM ausgeführten mathematischen Operationen sind wie im IEEE-754-Standard beschrieben. Mit dem Abschied von strictfp wird auch die Klasse StrictMath irrelevant.

Details: https://openjdk.java.net/jeps/306