JDK-8141541 : Simplify Nashorn's Context class loader handling
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-11-05
  • Updated: 2016-10-13
  • Resolved: 2015-11-09
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.
8u112Fixed 9 b93Fixed
Nashorn Context objects currently have two class loaders: the one passed from the factory as the "application" class loader, as well as an optional "classpath" URL class loader loading classes specified by the optional -classpath command line argument. When a classPathLoader is present Context code is doing a lookup in classPathLoader with a fallback to appLoader. This should be simplified to a single class loader: when -classpath is specified the newly created URLClassLoader should simply have the appLoader as its parent.
nounit-hard: we'd need to create a setup with two classes with the same name coming from two different class loaders and verify that the one coming from the app loader is loaded.