RFR: 8026877: Error in opening JAR file when invalid jar specified with -Xbootclasspath/a on OpenJDK build

[Christian Thalinger]

Wow.  The change looks good.

On Oct 23, 2013, at 6:05 PM, David Holmes <david.holmes at oracle.com> wrote:

> This is a simple change with a complex background, so please bear with me. :)
> 
> Here's the background. There is a class sun.misc.PostVMInitHook that only exists in the Oracle JDK (closed sources). There is a fragment of code in create_vm that runs this hook, if present, as part of the VM initialization sequence. This class is also on the list of well known classes to preload during early VM initialization (Universe::Genesis()->SystemDictionary::initialize()).
> 
> The problem arises when an invalid jar file, eg a zero-length dummy.jar, is specified on -Xbootclasspath.
> 
> In the Oracle JDK you will likely never discover that the invalid jar is present. During VM initialization all classes are in the meta-index that point to rt.jar and the "lazy loading" approach doesn't examine other entities on the bootclasspath unless necessary. So dummy.jar is completely ignored until the system classloader starts to load classes - at which point the bootloader upon not finding the class in the meta-index searches the bootclasspath, finds the invalid jar file and throws a ClassNotFoundException with a message about an invalid jar file. However the system (or extensions) loader expects the bootloader to throw such an exception if the required class can not be found on the bootclasspath (which it can't) and so continues to load it from the classpath and the application continues oblivious to the invalid jar. This is arguably not a good thing but not the subject of this particular change. ;-)
> 
> In the OpenJDK the PostVMInitHook class does not exist so when preloading fails to find it in rt.jar as expected, the bootloader starts searching for it and encounters the invalid dummy.jar. So as previously described it triggers ClassNotFoundException to be thrown. However, the exception throwing logic in the VM has to watch for trying to throw exceptions during early VM initialization when the VM is not really ready to throw the exception. It sees VM initialization is still in progress so it instead calls vm_exit_during_initialization and the user sees:
> 
> Error occurred during initialization of VM
> java/lang/ClassNotFoundException: error in opening JAR file <Zip file open error> dummy.jar
> 
> So the Oracle JDK effectively ignored the invalid jar file while the OpenJDK aborts during VM initialization.
> 
> There is a simple "fix" that allows the OpenJDK to behave the same as the Oracle JDK - we remove the PostVMInitHook class from the list of classes to preload. There's really no need for it to be preloaded and create_vm loads numerous classes that are not preloaded, so we simply handle this the same way. Now not finding the class during VM initialization doesn't trigger an exception (and if it did the logic would ignore it anyway).
> 
> http://cr.openjdk.java.net/~dholmes/8026877/webrev/
> 
> Thanks for reading this far :)
> 
> David