Skip to content
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

Closed
zakkak opened this issue Jun 14, 2021 · 12 comments

Comments

@zakkak
Copy link
Contributor

zakkak commented Jun 14, 2021

The recently pushed to graal master oracle/graal@5013ca7 states that

--initialize-at-build-time without arguments has been deprecated and will be removed in GraalVM 22.0.

As Quarkus is currently using this option


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.

@stuartwdouglas
Copy link
Member

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.

@geoand
Copy link
Contributor

geoand commented Jun 15, 2021

What is the justification for removing this?

Is there any way we can influence this decision?

cc @maxandersen

@zakkak
Copy link
Contributor Author

zakkak commented Jun 15, 2021

What is the justification for removing this?

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).
In any case let's wait for an official answer :)

Is there any way we can influence this decision?

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 --initialize-at-build-time= and be more precise on what we want (and know it's safe) to be initialized at compile time. This will make using Quarkus with 3rd party libraries (that are not supported through our extensions) easier I believe, since it will not force those libraries to be initialized at build time.

@maxandersen
Copy link
Member

@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.

@zakkak
Copy link
Contributor Author

zakkak commented Jun 15, 2021

@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.

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.

Those frameworks should just not use the flag;

I guess you mean they should use --initiailize-at-run-time per https://quarkus.io/guides/writing-native-applications-tips#delaying-class-initialization. AFAIK there is no way to not use --initialize-at-build-time= in Quarkus.

not remove our ability to find issues sooner rather than later.

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?

@maxandersen
Copy link
Member

Correct :)

@maxandersen
Copy link
Member

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.

@n1hility
Copy link
Member

+1 We want Opt-out, not opt-in

@geoand
Copy link
Contributor

geoand commented Jun 17, 2021

I opened #17986 based on our discussion today with the GraalVM team

geoand added a commit that referenced this issue Jun 18, 2021
Use the GraalVM API  instead of flag to force build-time init
@geoand
Copy link
Contributor

geoand commented Jun 23, 2021

With #17986 in, should we close this or leave it open to track future enhancements?

@zakkak
Copy link
Contributor Author

zakkak commented Jun 23, 2021

Closing it for now. I think we should open a new issue for possible enhancements.

@zakkak zakkak closed this as completed Jun 23, 2021
@jerboaa
Copy link
Contributor

jerboaa commented Sep 3, 2021

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants