Bug ID: JDK-8027361 Some uses of assert statements in default methods in bootclasspath cause VM crash

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
hs25Resolved

In the course of fixing JDK-8005294, versions of the patch for this fix added assert statements to a new default method in java.lang.reflect.AnnotatedElement, a type on the bootclasspath.

Such code compiled fine. When any attempt was made to run the VM with this libraries change, the VM would exit with

    Error occurred during initialization of VM
    java.lang.UnsatisfiedLinkError: java.lang.Class.getClassLoader0()Ljava/lang/ClassLoader;
        <<no stack trace available>> 

which was interested to debug. When the asserts were removed from the code, the resulting JDK was built and run fine. The code in question, with assert statements commented out can be found at

        http://cr.openjdk.java.net/~darcy/8005294.4/

It would be a serious limitation if asserts could not be used in default methods on the bootclasspatch. I have not investigated what other conditions, if any, are needed to trigger the problem.

Since this is another instance of the "can't use asserts in some core classes", closing as not an issue.
25-11-2013
This is not a VM problem.
24-11-2013
AnnotatedElement is normally initialized before java.lang.Class has been initialized, so if the static init now requires that Class is initialized (which it does to call desiredAssertionStatus) we are changing the very delicate bootstrap initialization order. TraceClassInitialization (in debug VM) shows the normal order: 0 Initializing 'java/lang/Object' (0xa1ab5240) 1 Initializing 'java/lang/CharSequence'(no method) (0xa1ab6ad0) 2 Initializing 'java/lang/String' (0xa1abb9e0) 3 Initializing 'java/util/Comparator'(no method) (0xa1b38560) 4 Initializing 'java/lang/String$CaseInsensitiveComparator'(no method) (0xa1b38a30) 5 Initializing 'java/lang/System' (0xa1acb530) 6 Initializing 'java/lang/ThreadGroup'(no method) (0xa1ae09f0) 7 Initializing 'java/lang/Thread' (0xa1addc88) 8 Initializing 'java/security/Permission'(no method) (0xa1b3ba18) 9 Initializing 'java/security/BasicPermission'(no method) (0xa1b3bb78) 10 Initializing 'java/lang/RuntimePermission'(no method) (0xa1b3bcd8) 11 Initializing 'java/security/AccessController'(no method) (0xa1b3d458) 12 Initializing 'java/security/AccessControlContext' (0xa1ad4da8) 13 Initializing 'java/lang/reflect/AnnotatedElement'(no method) (0xa1abdea0) <===== AnnotatedElement 14 Initializing 'java/lang/reflect/GenericDeclaration'(no method) (0xa1abe048) 15 Initializing 'java/lang/reflect/Type'(no method) (0xa1abe2b0) 16 Initializing 'java/lang/Class' (0xa1ac4318) <====== Class There will always be core classes that can not contain assert statement due to initialization issues and we may just have to add AnnotatedElement to that list.
24-11-2013
I wonder if desiredAssertionStatus has been updated to handle interfaces properly? Can we use a debug, or instrumented VM to print out what the actual exception stacktrace is?
23-11-2013
If you could please analyze the hierarchy and the problem and then we could discuss it and see if this is related to any other known issues that would be a huge help.
28-10-2013
Attaching javap output from the version of AnnotatedElement which triggered the error in VM initialization.
28-10-2013