XStream 1.4.19 and Java 17 fails in JVM static initializer

[surfing]

We have an XStream dependency and it fails with Java 17 in the static block of class com.thoughtworks.xstream.core.JVM with

Caused by: java.lang.NullPointerException: Cannot invoke "java.util.TimeZone.getRawOffset()" because "tz" is null at java.base/sun.util.cldr.CLDRTimeZoneNameProviderImpl.toGMTFormat(CLDRTimeZoneNameProviderImpl.java:273) at java.base/sun.util.cldr.CLDRTimeZoneNameProviderImpl.deriveFallbackName(CLDRTimeZoneNameProviderImpl.java:193) at java.base/sun.util.cldr.CLDRTimeZoneNameProviderImpl.deriveFallbackNames(CLDRTimeZoneNameProviderImpl.java:135) at java.base/sun.util.cldr.CLDRTimeZoneNameProviderImpl.getZoneStrings(CLDRTimeZoneNameProviderImpl.java:125) at java.base/sun.util.locale.provider.TimeZoneNameUtility.loadZoneStrings(TimeZoneNameUtility.java:86) at java.base/sun.util.locale.provider.TimeZoneNameUtility.getZoneStrings(TimeZoneNameUtility.java:72) at java.base/java.text.DateFormatSymbols.getZoneStringsImpl(DateFormatSymbols.java:849) at java.base/java.text.DateFormatSymbols.getZoneStringsWrapper(DateFormatSymbols.java:843) at java.base/java.text.DateFormatSymbols.getZoneIndex(DateFormatSymbols.java:812) at java.base/java.text.SimpleDateFormat.subParseZoneString(SimpleDateFormat.java:1735) at java.base/java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:2173) at java.base/java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1545) at java.base/java.text.DateFormat.parse(DateFormat.java:397) at com.thoughtworks.xstream.core.JVM.<clinit>(JVM.java:151)

JVM: 17 (Red Hat, Inc. 17+35) OS: Linux 5.4.0-74-generic amd64

[joehni]

Well, all unit tests have passed for the release, even with Java 17 runtime and the JVM class is always in use. My environment is not that different, but I can also run XStream's diagnostics without problem, which will also use the JVM class and its static initializers:

~ $ java -cp .m2/repository/com/thoughtworks/xstream/xstream/1.4.19/xstream-1.4.19.jar com.thoughtworks.xstream.core.JVM
XStream JVM diagnostics
java.specification.version: 17
java.specification.vendor: Oracle Corporation
java.specification.name: Java Platform API Specification
java.vm.vendor: Eclipse Adoptium
java.vendor: Eclipse Adoptium
java.vm.name: OpenJDK 64-Bit Server VM
Version: 17.0
XStream support for enhanced Mode: true
XStream support for reduced Mode: true
Supports AWT: true
Supports Swing: true
Supports SQL: true
Java Beans EventHandler present: true
Standard StAX XMLInputFactory: com.sun.xml.internal.stream.XMLInputFactoryImpl
Standard StAX XMLOutputFactory: com.sun.xml.internal.stream.XMLOutputFactoryImpl
Standard Base64 Codec: class com.thoughtworks.xstream.core.util.Base64JavaUtilCodec
Optimized TreeSet.addAll: true
Optimized TreeMap.putAll: true
Can parse UTC date format: true
Can create derive ObjectOutputStream: true
Reverse field order detected for JDK: false
Reverse field order detected (only if JVM class itself has been compiled): false
~ $ java -version
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment Temurin-17.0.1+12 (build 17.0.1+12)
OpenJDK 64-Bit Server VM Temurin-17.0.1+12 (build 17.0.1+12, mixed mode, sharing)
~ $ uname -a
Linux 5.15.26-gentoo-x86_64 #1 SMP Sat Mar 12 11:18:39 CET 2022 x86_64 Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz GenuineIntel GNU/Linux

[surfing]

Thanks for the quick answer. It seems a bug or different behaviour in the OpenJDK flavour which is installed at our CI system. I tested it with the latest OpenJDK bundled with Ubuntu and it works here, too. Do you want xstream to be more failsafe? I think it is just a matter of catching RuntimeException on the to tests. If you consider it I can send a PR.

[surfing]

Thanks for committing the change and improving the library. The way you did it does not show up as my contribution which is not very kind.

[joehni]

Sorry, if you feel disappointed, but this patch should not have been necessary in the first way. It simply covers some ill-behaving Java runtimes. Since it was not possible to apply the patch to the 1.4.x maintenance branch (that is still Java 1.4 compilable), it was way faster to simply add the two lines directly.