On Mon, 1 Aug 2022 16:23:59 GMT, Ao Qi <[email protected]> wrote: > The issue comes from > https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357. > > If Loom is not supported, two XMLDecoder tests would fail. The issue could be > reproduced by zero, for example: > > > -------------------------------------------------- > TEST: java/beans/XMLDecoder/8028054/TestConstructorFinder.java > ... > Caused by: java.lang.UnsupportedOperationException: VM does not support > continuations > at > java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49) > at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52) > ... 9 more > ... > > -------------------------------------------------- > TEST: java/beans/XMLDecoder/8028054/TestMethodFinder.java > ... > Caused by: java.lang.UnsupportedOperationException: VM does not support > continuations > at > java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49) > at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52) > ... 9 more > ... > --------------------------------------------------
The two XMLDecoder tests in this directory are problematic because they directly load and cause the initialization of all classes in java.base/java.lang, including non-public classes such as java.lang.VirtualThread$VThreadContinuation. Loading and initialization of this class requires the loading and initialization of its super class that is our implementation of delimited continuations and is deeply tied to VM support. The Zero port doesn't have this support and instead uses an alternative implementation of virtual threads where each virtual thread is bound to an OS thread. So no change to Class.forName, instead we are just modifying the two tests so that they don't needless try to initialize JDK internal classes that are dependent on VM support. ------------- PR: https://git.openjdk.org/jdk/pull/9704
