0

Plenty of java applications today contain executable code and a set of interfaces. These interfaces are then used by implementors to create a set of classes that should function when loaded into the application.

However, these implemented classes aren't known to the main application at build-time, which is where GraalVM and spring boot 3 native images expect to have them.

In the past with Java, you could simply extend the classpath to include additional classes, which would then be picked up and loaded by the application dynamically. I believe this is exactly how tools like Tomcat and Jenkins function today with .war files.

I attempted to recreate this functionality using

var resource = ClassLoader.getSystemResourceAsStream("./MyClass.class);
RuntimeClassInitialization.initializeAtRunTime(MyClass.class);

However, it seems as though this isn't supported at all (and I can't find any examples of it) within native image compilation.

Is the case possible where an application can start, dynamically load code from an external file, and execute that code within the GraalVM Native framework?

StevenPG
  • 311
  • 4
  • 16
  • It is [possible](https://www.graalvm.org/latest/reference-manual/native-image/metadata/ExperimentalAgentOptions/#support-for-predefined-classes), but all the bytecode should be known at image build time. A native image cannot load arbitrary classes because it does not have bytecode interpreter built in. – peterz May 22 '23 at 12:43
  • That was my fear @peterz, it seems if one is writing a new application using the JDK with the intent to convert to native image in the future, the plugin architecture I mentioned in my question isn't especially feasible. – StevenPG May 22 '23 at 13:31

0 Answers0