JDK-8074105 : Remove support for downloaded JavaFX classes
- Type: Enhancement
- Component: deploy
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- Submitted: 2015-03-02
- Updated: 2015-09-29
- Resolved: 2015-03-19
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 |
|---|---|
8u60Fixed  |
9 b59Fixed |
Related Reports
|
Relates :
|
Description
While investigating JDK-7126229 last week, I see that we still have implementation of JNLPPreverifyClassLoader used in both plugin and webstart. This was added for old version of javafx jars that were downloaded by the java installer and verified during install, so that no security dialog for them would show when running the first javafx app/applet. There does not seem to be any reason to maintain them, and their existance complicates the existing classloader chain. There is also a whole bunch of code in Plugin2ClassLoader and Applet2ClassLoader to special case when reflection code is executed on these classes (see Applet2ClassLoader.findClass(), JNLP2ClassLoader.findClass(), and Plugin2ClassLoader.needTAoApplyWorkarround())
Comments
|