JDK-8073423 : Remove LazyClassPathEntry support if no longer needed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-02-18
  • Updated: 2022-05-06
  • Resolved: 2015-06-29
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 b74Fixed
Related Reports
Relates :  
Description
Removing meta-index support from the JVM may have made LazyClassPathEntry support useless.  If so, then remove support for LazyClassPathEntry from the JVM.
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d76f3398c6eb User: lana Date: 2015-07-22 21:33:30 +0000
22-07-2015

URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d76f3398c6eb User: hseigel Date: 2015-06-29 19:31:06 +0000
29-06-2015

The LazyBootClassLoader option affects -Xbootclasspath/a on JDK-9. JTReg test hotspot/test/runtime/LoadClass/LoadClassNegative.java, for JDK-8020675, contains an empty jar file. Without LazyBootClassPath, the JVM will try to open and read the empty jar file when setting up the bootstrap search path. When the open fails, it's treated as a fatal error because the JVM is still initializing. (There's an EXCEPTION_MARK in setup_search_path() that causes this.) With lazy loading, the JVM does not try to open the jar file until after the JVM has initialized. And, the open attempt is done thru LazyClassPathEntry::open_stream(). The open failure does not cause the JVM to terminate and the JTREG test passes. I'm not sure yet what the correct behavior is, but I don't think we should terminate the JVM if a jar file is bad.
23-06-2015