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