JDK-8231924 : Field::getGenericType triggers loading and linking that may fail with LinkageError
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Affected Version: 14
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2019-10-07
  • Updated: 2019-11-05
  • Resolved: 2019-11-05
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.
JDK 14
14Resolved
Related Reports
Duplicate :  
Relates :  
Description
The changes in JDK 14 via JDK-8212117 to align Class.forName with its specification may need follow on work in the core reflection code that obtains the Type of a field with parameterized type.

The sighting on core-libs-dev is here:
  https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-October/062747.html

In the example, Service can be loaded but not linked. It may be that makeNamedType needs to catch NoClassDefFoundError so that TypeNotPresentException can be thrown. 
Comments
The JDK-8212117 changes were backed out by JDK-8233091, and so this bug is gone as well.
05-11-2019

[~mchung] is right. The linking, and in particular the verification, of `Service` -- new in JDK 14! -- is triggering the loading of `OptionalService`. Notice the code `this(new OptionalService() {});` in the body of the no-args ctor of `Service` ... really the code is `this(new OptionalService$1234());` and so the verifier must load class `OptionalService$1234` to check that it's compatible with the formal parameter type of the 1-arg ctor. (I'm not going to say what the formal parameter type is, because it doesn't matter for the next sentence.) The loading of class `OptionalService$1234` triggers loading of its indicated superclass, which happens to be `OptionalService`, which happens to be not present.
17-10-2019

While I can argue that there is no need for this API to link the classes involved, there is no API available to it to use to load a class without linking. Only ClassLoader.loadClass can be used for that, but we can't use it here because we don't know if we can trust the ClassLoader.
10-10-2019

The class loading may be triggered by verification during linking.
09-10-2019

Again let me question whether this code should actually be linking the class involved?
09-10-2019

We probably need to look at all internal uses of Class.forName to see how LinkageErrors might need to be adapted (though most places should pass LinkageErrors through). Or whether the code involved should only be loading, rather than linking the target class.
07-10-2019