"Pre-main" event support in native image

[tomas-langer]

Feature request

Is your feature request related to a problem? Please describe.
When starting within native image, we need to carry out some maintenance of the framework (I am from project Helidon). This includes setting up logging, reading configuration and registering it etc.
Currently we need to put this kind of initialization into places we hope will be executed early enough, before user code, which is not always the case.

Describe the solution you'd like.
It would be great if I could register a "pre-main" event listener - a class, or static method that would be invoked when the native image starts, but before user code is invoked.

Describe who do you think will benefit the most.
Developers of libraries and frameworks which depend on GraalVM
GraalVM users

Describe alternatives you've considered.
I could not find any alternative solution to this problem

[fniephaus]

We already have support for startup hooks in Native Image (example use) but this is private API. We may be able to make this available in our public API somehow. I believe that would fit your use case, right?

[olpaw]

@tomas-langer the window to add new features to 22.3 is already closed. We can provide public API support for adding startup hooks in 23.0. Until then please use the internal variant com.oracle.svm.core.jdk.RuntimeSupport that @fniephaus mentioned above. You will need to add --add-exports=org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk=ALL-UNNAMED to be able to use RuntimeSupport from your feature on classpath. (If your feature is in a proper java module use the module name instead of ALL-UNNAMED)

[tomas-langer]

This is not required immediately, so we can wait for 23. For my purposes it should be sufficient to have a Runnable (not sure what the boolean parameter means, maybe this would be significant).
We are moving now to use public APIs only (as soon as you release 22.3), so definitely would prefer to have this in public API.

Thank you

[wirthi]

@tomas-langer we discussed that internally and we have some concerns around Java compliance with that feature. In a perfect world, you would not need that - the same thing as in JIT mode would work, right? So why does it not work out of the box with native image, where do we behave differently than the JIT mode in initialization order, etc.?

[tomas-langer]

The difference is that when using JIT, the environment cannot change between initialization and runtime.
There are two main examples that are really important:

1. Configuration - there is a different configuration at runtime as compared to build time. We need to read the configuration before other things start happening in the application
2. Logging - runtime logging may differ from build time. We want to read the logging configuration before application starts