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

[Coleen Phillimore]

This looks good.  Do we use sun.misc.PostVMHook for anything?

Coleen

On 10/23/2013 9:05 PM, David Holmes 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