Unraveling the Java Class‑Object Bootstrap: Which Comes First?

In the Java object model, every class is an instance of java.lang.Class, and java.lang.Object is a class, but the claim that Object is also an instance of Class is incorrect.

All classes ultimately inherit from Object, and Class itself is a subclass of Object.

The classic “chicken‑or‑egg” dilemma is solved by a bootstrap process that initializes both core types together.

The JVM allocates memory for the most important core types (e.g., java.lang.Object and java.lang.Class) in a partially‑initialized state, links their references, and then completes their full initialization.

During this bootstrap phase, the HotSpot VM uses the C++ class Universe to track the system state, exposing two key functions:

static bool is_bootstrapping() { return _bootstrapping; }
static bool is_fully_initialized() { return _fully_initialized; }

The function Universe::genesis() creates the core type instances and calls SystemDictionary::initialize(), which in turn invokes SystemDictionary::initialize_preloaded_classes() to create java.lang.Object, java.lang.Class, and other essential classes.

After these classes are loaded, Universe::fixup_mirrors() resolves the circular references between Object and Class, completing the bootstrap.

// Fixup mirrors for classes loaded before java.lang.Class.
Universe::initialize_basic_type_mirrors(CHECK);
Universe::fixup_mirrors(CHECK);

void Universe::fixup_mirrors(TRAPS) {
  // Walk over already allocated permanent objects (mostly classes)
  // and fix their mirrors. The number of objects at this point is very small.
}

Thus, the JVM can have both Object and Class available without a true ordering conflict, similar to bootstrap mechanisms in other runtimes like JavaScript, Python, and Ruby.