search

oracle / graal

GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
https://www.graalvm.org
Other
20.22k stars 1.62k forks source link

No way to add resource bundles from Feature #710

Open stuartwdouglas opened 5 years ago

stuartwdouglas commented 5 years ago

Most similar options have a programatic API that can be used to avoid the need for extensive command line options when doing a build, however com.oracle.svm.core.jdk.LocalizationSupport does not seem to have this.

With RC6 I could just get LocalizationSupport from the ImageSingletons and use it directly, however all its methods have been made package private, so this is no longer really an option. It would be great if there was a programatic API to enable this.

cstancu commented 5 years ago

@stuartwdouglas those methods were not intended to be part of the API and that's why they changed without notice. Can you share how/what methods you were using exactly so we can design an API?

stuartwdouglas commented 5 years ago

Basically just to add resource bundles programatically without having to specify 'IncludeResourceBundles'. The command line basically requires users to have knowledge of all frameworks internal resource bundles, if the framework just includes a feature that registers them then this is no longer required.

d-kozak commented 9 months ago

I believe this issue is by now resolved by reachability metadata. In case there is still a need for an API, please reopen the issue and specify your use case.

Sanne commented 9 months ago

Hello,

representing the Hibernate team here, but I'm also an architect on the Quarkus team.

We have no plans to use the reachability metadata, sorry but I don't think that would be the preferred solution for libraries which intend to provide out of the box support for GraalVM: it's not ideal to maintain such metadata in a separate repository which gets out of synch with our QA and release planning; also the use of the reachability metadata requires additional tooling to be applied at build time which we don't expect everyone to use; for example the Quarkus project has no plans to integrate such tooling either as we found no benefit in doing so.

Hibernate provides an out of the box GraalVM "Feature" which is meant to help end users by providing the right defaults; being able to register required resources by default would be a nice improvement for our users - I primarily created this for Spring users and consumers of other or in-house frameworks, sure some might be using the metadata repository but this is not possible for everyone.

None of this is necessary for Quarkus as we can automatically activate such options as arguments to native-image so I'm not sure about re-opening this issue, it's certainly not a blocker for us, but I thought I'll let you know I feel it's a mistake in terms of the more broader user base benefit.

maxandersen commented 9 months ago

@d-kozak even if Quarkus and others add support for reachabilty-metadata it does not solve it for libraries and frameworks that prefer being able to tune it or deliver it as part of their releases.

reachability-metadata is at best something that enables others to fix/improve it for some libraries.

I've checked and neither me, @Sanne nor @stuartwdouglas has the power to reopen this so @d-kozak can you reopen or you prefer we create a new duplicate issue?