RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class
brent.christian at oracle.com
Fri Sep 6 00:09:29 UTC 2019
@jls tags added (and as long as we're in Class.java, I added @jls to the
3-arg Class.forName(), which has an equivalent paragraph).
On 9/5/19 3:30 PM, Joe Darcy wrote:
> For the doc changes in MethodHandle, please supplement the paragraph
> 1937 * <p>
> 1938 * Note that this method throws errors related to loading
> and linking as
> 1939 * specified in Sections 12.2 and 12.3 of <em>The Java
> 1940 * Specification</em>.
> with @jls tags like
> @jls 12.2 Loading of Classes and Interfaces
> @jsl 12.3 Linking of Classes and Interfaces
> as done elsewhere in the base module. I think it would be slightly
> better to remove the section numbers from the main text but keep them in
> the @jls tags since it is now possible to check that the listed name of
> the section matches what is in the JLS.
> On 9/4/2019 2:12 PM, Brent Christian wrote:
>> Please review my fix for JDK-8212117. The webrev is here:
>> There is also a CSR 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  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) in the Launcher, by way of
>> (using the 3-arg Class::forName, detailed in the bug report),
>> (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 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