JVM startup has long been under-specified. Section 5.2 of the JVM Specification, despite being called "Java Virtual Machine Startup", actually describes the startup of an application written in the Java language. The description focuses on how an initial class, nominated by the user, is loaded, linked, initialized, and its static `main` method executed. Enhancements to the Java language in Java 25 (instance `main` methods from JEP 512) led to minor changes that allow for the initial class to be instantiated too.

The description in JVMS 5.2:
- adds little value over the Java-centric description in JLS 12.1;
- fails to explain how the JVM could already be in a state where it can create an initial class;
- fails to acknowledge that if a user-defined class loader loads the initial class, then code to implement that class loader must already have been loaded, including the `java.lang.ClassLoader` class and a user-provided subclass;
- ignores other components of the Java Platform, notably the JNI Invocation API which provides a standard way to create a JVM from scratch and is widely used by native launchers such as `java`.

Many aspects of JVM startup involve behavior that is beyond what can be expressed in bytecode, e.g., the operation of the bootstrap class loader which necessarily exists before the `java.lang.ClassLoader` class is loaded. Other aspects of JVM startup involve subsystems that are either OS-specific, such as signal handling, or controlled by other Java Platform specifications, such as the operation of the module system.

JVMS 5.2 would ideally "thread the needle" by identifying the minimal steps needed to create the JVM and reach execution of the first "useful" bytecode. It should acknowledge that the JVM is not alone -- startup is driven by an external `java`-style launcher, and should often defer to other Platform components. It should also avoid restricting implementers' freedom except where it is necessary to preserve user-visible behavior specified elsewhere in the JVMS.