skip to content

Class Loading & Initialization

3 roadmaps33 questions

How a type gets from raw bytes to a usable runtime class: loading, verification, preparation, resolution, initialization, and the loader hierarchy that gives each type its identity. Interviewers reach for it when they want depth, since NoClassDefFoundError and "X cannot be cast to X" only make sense once you know this.

on this pageshow

explore

questions

page 2 of 2

A framework generates a proxy class as a byte[] at runtime. What are the ways to turn those bytes into a usable runtime type on a modern JVM, and how do the options differ in visibility, access and lifetime?

level: seniorimportance: nice to knowfreq 25%

basics

~20 s

Three routes: define through a custom ClassLoader's protected defineClass; call MethodHandles.Lookup#defineClass (Java 9+) to define into the lookup class's own loader and package with its access; or Lookup#defineHiddenClass (Java 15+) for a class with no name in the loader's table, private access to its host, and lifetime tied to it.

open as a page

Some JVM runtime types never come from a classfile at all — array types such as `String[]` are one example. How does the JVM create such types, and how do runtime-generated types like lambda implementation classes come into existence?

level: seniorimportance: nice to knowfreq 24%

basics

~20 s

Array classes and primitive types have no binary representation: the JVM synthesises them directly, and an array class's defining loader is its component type's loader (bootstrap for primitive arrays). Lambda implementation classes do come from bytes, but bytes generated in memory at first execution and defined as hidden classes.

open as a page

A JVM service generates a large number of classes at run time and its start-up time is dominated by class loading. How does the bytecode verification phase factor into that cost, and what levers would you consider?

level: principalimportance: nice to knowfreq 22%

basics

~20 s

Verification is per-class work proportional to bytecode size and branch structure, and it is a significant part of class-load cost for application classes — bootstrap classes are trusted and skipped by default. Levers: generate fewer and smaller classes, reuse them, and use class-data archives that store already-linked classes, rather than disabling verification, which modern JDKs ignore.

open as a page

showing 31–33 of 33