JDK-8049371 : Update system and extension class loaders to support modular image
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.lang:class_loading
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-07-05
  • Updated: 2016-01-06
  • Resolved: 2014-09-17
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 9
9-repo-jigsawFixed
Description
The system and extension class loaders will require changes to work with a modular image.

As these class loaders are URLClassLoaders then a possible approach (that doesn't involve significant surgery) is to create a URL protocol handler that to support access for both class loading and resource files. This will likely be created to grant permissions too (see JDK-8047766).

A possible optimization is to seed these class loaders with the list of local packages so that they can avoid delegation. Minimally the extension class loader should not need to delegate for local packages unless -Xbootclasspath is set. Similarly the system class loader should not need to delegate unless there are 3rd party libraries in the ext directories (or -Xbootclasspath is set).
Comments
With a local package map then I assume the loaders will still delegate to the parent when called to load other classes. So I think the FX case is okay. The only issue would be if someone copies a JAR file into the ext directory with API packages that would normally be defined by the system class loader. In that case, the local package map would prevent the delegation and the wrong "version" of the classes would be used. The same concern with -Xbootclasspath/a or /p. I remember the startup results from that page. If we can, then it would be great to do some measurements both with and without a local package map to see if it helps. The hard part might be just finding some useful benchmarks to run.
03-09-2014
The system and extension class loaders have been updated in jake to work with the modular image. We will need to decide how to bring this over to Bertha. Further updates to the jimage protocol handler will likely required if it pushed in its current form. In addition we plan to update both of these class loaders to use the local package maps to avoid delegation for types that are known to be local. Mandy has a patch in progress that provides these maps in the modular image.
03-09-2014
JavaFX will remain as jfxrt.jar in the ext directory in Bertha. Unless we special case jfxrt.jar, the system class loader would need to delegate to the extension class loader. In addition, when ClassLoader.loadClass delegates to the null class loader, it calls JVM_FindClassFromBootLoader that returns null if the class is not found and avoids throwing CNFE. The performance measurement I did several years ago [1] shows that the cost of CNFE due to class loader delegation is insignificant. The packages of dynamic generated classes are unknown at link time. [1] http://cr.openjdk.java.net/~mchung/startup_measurement/startup.result.b61
03-09-2014