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?

## Two categories of "no classfile" It is tempting to assume every runtime type in a JVM began life as a `.class` file. Two large categories break that assumption, and they break it in different ways: 1. Types the JVM **creates** with no binary representation at all — array classes, primitive types, `void`. 2. Types that **do** have classfile bytes, but bytes that were generated in memory during the run and never existed as a file. ## Array classes: created, not loaded There is no artifact anywhere describing `String[]`. When the JVM needs the array type, it manufactures the runtime type itself: the members are fixed and known (a `length` field, `clone()`, and the members inherited from `Object`), the supertype relationships are defined by the specification (arrays are `Object` and implement `Cloneable` and `Serializable`), and covariance follows the component type. The rule people actually get asked about is the **defining loader**: an array class's defining loader is the defining loader of its component type. So `com.acme.Order[]` belongs to whichever loader defined `com.acme.Order`, while `int[]` — having a primitive component — is associated with the bootstrap loader. Multi-dimensional types are built up recursively: creating `Order[][]` requires `Order[]`, which requires `Order`. Primitive types and `void` follow the same spirit: `int.class` and `void.class` are mirrors the JVM materialises during startup; there is nothing to read. A practical consequence: an array class cannot be "missing" independently of its component type. Any failure you see relates to the component type — reflectively requesting `Class.forName("[Lcom.acme.Order;")` fails only because `com.acme.Order` cannot be found. ## Runtime-generated classes: real bytes, no file The second category goes through the normal load path, just with bytes produced by a program rather than a compiler writing to disk. **Lambdas.** A lambda expression does *not* compile into an anonymous inner class file. The compiler emits an `invokedynamic` instruction whose bootstrap method is `LambdaMetafactory`. On the first execution of that call site, the metafactory spins a small class implementing the target functional interface, wired to the lambda body (which the compiler emitted as a private synthetic method on the enclosing class), and returns a `CallSite` that the JVM links permanently. Subsequent executions of the call site do no work. This design is why lambdas add no `Foo$$1.class` files to your JAR and why the strategy could be changed without recompiling code. **Hidden classes.** Since Java 15, generated helpers like these are defined through `MethodHandles.Lookup.defineHiddenClass(byte[], boolean, Option...)`. A hidden class: - is not discoverable by name (`Class.forName` cannot find it) and is not entered into a loader's class-name map; - cannot be named in another class's constant pool, so nothing can hold a static reference to it; - reports a synthetic name with an implementation-specific suffix in stack traces; - can be unloaded independently of its defining loader (a normal class cannot); - may be declared a *nestmate* of the lookup class, giving it private access. This replaced the internal `sun.misc.Unsafe.defineAnonymousClass`, which many frameworks had reached for and which was removed in Java 17. **Proxies and enhancers.** `java.lang.reflect.Proxy` generates a class implementing a requested set of interfaces and defines it into a loader you supply. Mocking frameworks generate subclasses; ORMs generate enhanced entity subclasses for lazy loading and dirty tracking; serialization libraries generate accessors. All of these use a bytecode library to build a `byte[]` and then a define call. Once defined, these classes are utterly ordinary: verified, resolved, initialized and JIT-compiled by the same rules as compiled-from-source classes. ## How to recognise them at runtime - `-verbose:class` / `-Xlog:class+load` shows a source of `__JVM_DefineClass__` (or similar implementation-specific text) for classes defined from a byte array rather than a located resource. - Stack frames containing names with `$$Lambda` and an implementation suffix, or proxy names like `jdk.proxy2.$Proxy31`, indicate generated types. - A steadily rising loaded-class count in `jstat` or JFR, with names that look generated, points at a code-generation hot spot. ## Why an interviewer cares This question separates candidates who model "class loading" as "reading files" from those who model it as "deriving types". The array case shows the JVM manufacturing types with no bytes; the lambda case shows bytes manufactured with no file; the hidden-class case shows the platform adding a *narrower* kind of type when the full "nameable, permanent, loader-scoped class" contract is more than a generated helper needs.