In JDK1.2 a JVM interface version check was added in order to catch the case where the VM is used with incompatible native libraries. This catches most configuration problems, but a user can still set -Xbootclasspath to an incompatible rt.jar/classes.zip. In many cases this will cause an exception during VM initialization, but in other cases a program might run for a while before failing.

One can argue that setting -Xbootclasspath is asking for trouble, but it would be nice if the JDK core classes contained some token the VM could verify on startup. This could be:

- existence of a certain class, e.g. sun.xxx.jdk122
- contents of a private static final field somewhere
- other things the VM can check without running Java code.

This would allow the VM to exit gracefully with a meaningful error message.

This issue originates in bug 4206670, where someone was trying to run Hotspot Beta1 with the jdk1.2beta3 classes.zip ...