[GR-42823] Add native-image API for defining built-in system-properties for image-runtime

[olpaw]

Based on @kristofdho's suggestion we should add an API method that allows users to define system-property key-value pairs that are automatically available at image runtime. This already exists internally as ImageSingletons.lookup(SystemPropertiesSupport.class).initializeProperty("property.name", "value") and should be made available though public API.

[olpaw]

Originally suggested here: #4862 (comment)

[kristofdho]

SystemPropertiesSupport already contains functionality to compute defaults at runtime if they are dependent on the runtime environment of the user. It would be nice if that could also be exposed, as something like initializeProperty(String key, Supplier<String> supplier).

[olpaw]

It would be nice if that could also be exposed, as something like initializeProperty(String key, Supplier<String> supplier)

Exposing the variant with the supplier requires a very compelling use-case, as this goes beyond what you can do on the JVM. Also note that the supplier-variant has less trivial semantics. On first access to java.lang.System#getProperties at runtime the suppliers are evaluated (see com.oracle.svm.core.jdk.SystemPropertiesSupport#ensureFullyInitialized). cc @christianwimmer @wirthi

[kristofdho]

For our usecase, before we switched to GraalVM native-image we were using Excelsior JET. This did not allow you to pass JVM properties to the exe directly, and this used environment variables.
So for backwards compatibility, we need to take these env vars into account and set certain properties accordingly. An example of such a property is java.awt.headless.
A secondary usecase is that we need to modify/override the value of java.library.path to include additional subfolders of the installation directory in which the native-image exe is located. And because the native-image compiled through GluonFX fails if there is an older JDK8 on the classpath gluonhq/substrate#940. Since only the initial resolution of the library uses this value, and transitive dependencies are handled by Windows and the PATH content, it suffices to overwrite java.library.path to just the dir of the exe and our additional subdirs.

For now we're doing everything in a helper class that sets all these properties accordingly, which we're calling as first thing in all our entrypoints.

[olpaw]

For now we're doing everything in a helper class that sets all these properties accordingly, which we're calling as first thing in all our entrypoints.

There is nothing wrong with that 🙂

[kristofdho]

There is nothing wrong with that 🙂

No there isn't, except if an additional entrypoint is created, whoever is doing it has to be aware of the obligatory boilerplate required to make native-image work as well.