> For many real world applications, you'd need to load classes that isn't known at compile time (e.g., a user supplied database jdbc connector).

I'm not familiar with some of the dev patterns here, but why not just load all the classes for the databases you want to support, from the top, and compile them all in? Is that not practical?

> just load all the classes for the databases you want to support

you cannot distribute some connectors (e.g., the oracle connector or the mysql connector), in the case of jdbc anyway.

And it's not always possible to know ahead of time the classes you want to pre-load, if your application is like eclipse with a plugin architecture which can allow users to install custom plugins.

It just hasn't been a limitation in the jvm so libraries end up depending on those tools.

A ton of stuff ends in up doing class loading, bytecode generation, dynamic serialization.

The easiest off the top of my head is webapp containers like Tomcat or Jetty. As it runs your load a whole zip file with a full set of jars on the fly afterwards.

AOT can deal with it. In Java 9 or 10, they added an ability to AOT compile modules. You can still do dynamic classloading with the result, and the JVM still warms up to higher peak performance than you get with a static AOT compiler alone.

The SubstrateVM flavour can't do dynamic classloading or go as fast as HotSpot, it's strictly less powerful and compatible. However the static points-to analysis it does along with other optimisations mean much smaller binaries and memory footprints. If those matter to you and you can sacrifice classloading, great. If you can't, experiment with HotSpot's AOT support (which also uses Graal under the covers) and you can get faster startup time, but without the memory savings.

Clojure apps are typically packaged as standalone uberjars. So, all the classes come from the dependencies that are declared at runtime. The problem you're describing is mostly associated with Java app servers.

Err typo, meant to say dependencies are declared at compile time.

Personally, I wonder why class-loading is not possible. In the end either a class exists in the closed-world that existed when the project was compiled, or it does not. Of course you cannot change the JDBC connector after it was compiled!

Maybe they could add a whitelist of "known" entry-points for class loading, as to avoid going through a list of 10,000 inner classes that existed at compile time but nobody will ever instance by name.

> Of course you cannot change the JDBC connector after it was compiled!

no, but you can add, dynamically at run time (such as from a user supplied file) a new implementation of the interface. And because as part of the JDBC interface, a connector is able to register itself too (via classloading magic).

JDBC is just an example of a common plugin architecture for extensible software. But perhaps one way to make this work with AOT is to bring along the AOT compiler, and AOT the connector jar when it is being loaded, and treat that binary same as any dynamically linked library!

> In the end either a class exists in the closed-world that existed when the project was compiled, or it does not

uh ? no, new classes are added at runtime all the time - at least in C++, dynamic loading of plug-ins is extremely common

What I'm saying is that it breaks when you do a Class.forName(...), while if such class is known to exist at compile time, it is the same as a switch statement on the class name that returns a new object of the same type; and that second form would be a valid operation.

> What I'm saying is that it breaks when you do a Class.forName(...),

but you don't do this. you register the classes according to what is on your file system and you load one that matches your criterions or you ask your user to choose one in a UI of some kind.

SubstrateVM does support that pattern.

What people are talking about is different. It's when the app genuinely loads plugins that weren't available at compile time, or generates bytecode on the fly.