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.
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 8 | JDK 9 |
|---|---|
8u112Fixed  |
9 b93Fixed |
Description
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.
Comments
|