Building a GraalVM Native Image from a Java application requires explicit configuration of reflection, proxies, and other dynamic mechanisms — unlike the JVM which handles these automatically at runtime. The reason lies in the closed-world assumption: Native Image performs ahead-of-time compilation and reachability analysis, so all execution paths must be known at compile time. The JVM acts as a dynamic runtime hub resolving symbolic references and method calls on the fly, but Native Image removes that hub entirely. A practical example using the Foreign Function & Memory API illustrates how a native call that works fine on the JVM fails in a native build without a configuration file describing the call signature. Configuration is therefore not a flaw but a fundamental consequence of moving Java's dynamic behavior into the static compilation world.