-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--initialize-at-build-time without arguments to be deprecated (in 21.2?) and will be removed in GraalVM 22.0. #17887
Comments
I just had a quick look at this, and one of the really problematic parts about this is that every dependency class must also be registered for build time registration as well, or an error is thrown. e.g. if I tell graal to load our main class at build time, we need to also tell it to load every single class used by our static init recorders, or the build fails. |
What is the justification for removing this? Is there any way we can influence this decision? cc @maxandersen |
I have started oracle/graal#3476 to ask about the justification for removing it. My understanding/guess is that because there are classes that cannot be initialized at runtime, or even if they do they cause issues (e.g. oracle/graal#3417 (comment)), the GraalVM team wants to remove the option of initializing all classes to force the developers who want to be more aggressive, when it comes to build time initialization, to explicitly specify the classes they want to initialize at build time (and as a result be more aware of what works and what not).
I personally find no reason in doing this, unless it's to buy us some time. My opinion is that no matter if the option gets removed or not, we should avoid using |
@zakkak this goes against how we appraoch things from quarkus side - we want the ability to have users and framework writers forced to update for native-image; not the other way around. Those frameworks should just not use the flag; not remove our ability to find issues sooner rather than later. |
I see how that helps getting better performance, but at the same time it removes part of the "developer joy" IMO as it raises the entry barrier.
I guess you mean they should use
I don't see what would be the issue in this case, as those frameworks are not supported in the first place. Do I understand correctly that what you imply here is that the Quarkus approach to initialize everything at build time, is not only to improve performance, but also to minimize the risk of runtime failures due to unsupported features becoming reachable through runtime initialization? Thus making Quarkus more reliable in both aspects? |
Correct :) |
just to be clear we are fine tweaking the options here but the issue is that list of classes we would need to add here would be quite gigantic and we would prefer to explicitly state what is at runtime rather than what is a buildtime. |
+1 We want Opt-out, not opt-in |
I opened #17986 based on our discussion today with the GraalVM team |
Use the GraalVM API instead of flag to force build-time init
With #17986 in, should we close this or leave it open to track future enhancements? |
Closing it for now. I think we should open a new issue for possible enhancements. |
@maxandersen @n1hility Not sure what the plan is for ImageIO support in Quarkus, but it seems quite challenging to do if build-time-init-for-everything stays. If the answer is to use runtime initialization feature for (relevant/all) AWT classes, this is quite fragile and might be fairly JDK specific (maintenance challenge on Graal/JDK updates). See #19789 for some info. |
The recently pushed to graal master oracle/graal@5013ca7 states that
As Quarkus is currently using this option
quarkus/core/deployment/src/main/java/io/quarkus/deployment/pkg/steps/NativeImageBuildStep.java
Line 556 in fc31727
we need to come up with an alternative implementation.
It looks like the way forward is to explicitly register the classes and packages we want for build time initialization instead of asking GraalVM to initialize everything at build time.
The text was updated successfully, but these errors were encountered: