Java / GraalVM Interview questions
Why doesn't Native Image support dynamic class loading by default?
Native Image's entire performance model rests on a closed-world assumption: every class that could ever run must be known and analyzed at build time, so the compiler can strip out anything unreachable and compile the rest directly to machine code with no runtime lookup overhead.
Dynamic class loading - pulling in a class from a JAR or byte array the application doesn't reference until runtime, based on user input or a plugin directory scan - fundamentally breaks that assumption, because the analysis literally cannot see code that doesn't exist yet at build time.
Some limited support exists (e.g. defining classes from bytes when the class shape is otherwise known), but general-purpose dynamic classloading of arbitrary, previously-unseen classes isn't supported the way it is on a standard JVM, which is why plugin-architecture applications are among the harder cases to port to Native Image.
More Related questions...
