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.
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
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.