RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

Brent Christian brent.christian at oracle.com
Wed Sep 4 21:12:25 UTC 2019


Please review my fix for JDK-8212117[1].  The webrev is here:


There is also a CSR[2] in need of review.

The spec for the 2-arg and 3-arg Class.forName() methods states they 
will "locate, load, and link" the class, however the linking part is not 
ensured to happen.

Although the VM spec allows flexibility WRT when classes are linked, 
this is a corner where the Class.forName() spec is not being upheld. 
While this is not an issue for most usages,  8181144 [3] demonstrates 
how this can be a problem (with the debugging interface, in this case).

This fix ensures that linking happens during the course of 
Class.forName().  Class.forName() already @throws LinkageError, so no 
spec change is needed there. MethodHandles.Lookup.findClass() needs a 
small spec update, due to calling Class.forName with init=false,

Of course Errors are not required to be caught.  It is therefore 
possible that the new behavior could introduce previously unseen, 
possibly unhandled LinkageErrors.  A new VM flag 
(-XX:+ClassForNameDeferLinking) is introduced to restore the previous 
behavior (to keep such code running until it can be updated).

This change surfaced a couple new "A JNI error has occurred" situations 
(see 8181033[5]) in the Launcher, by way of
(using the 3-arg Class::forName, detailed in the bug report[4]),
(using the 2-arg Class::forName).

The Launcher is updated to maintain non-confusing error messages :).

The new test included with this fix ensures that 8181144[3] is 
addressed.  Thanks go to Serguei Spitsyn for writing the test.

Automated corelibs and hotspot tests pass cleanly.


1. https://bugs.openjdk.java.net/browse/JDK-8212117

2. https://bugs.openjdk.java.net/browse/JDK-8222071

3. https://bugs.openjdk.java.net/browse/JDK-8181144


5. https://bugs.openjdk.java.net/browse/JDK-8181033

More information about the hotspot-dev mailing list