Reconsider the choice of making everything in native build time initialized by default

[gsmet]

There has been quite a lot of discussions around $SUBJECT and I would like us to have a proper discussion about it and get the outcome properly documented in an ADR so that we have a clear status about it.

Quarkus made the choice very early of initializing everything in native at build time except if specified otherwise.

Quarkus adoption has skyrocketed, native adoption too and it can make running Quarkus in native quite a headache, compared to when running other frameworks.

While I think we should continue to do that when we have an extension, and I think we should have a list of vetted packages for each extension we have, I'm not sure we should do it by default for:

• application code
• libraries we know nothing about

An example of this issue is here: #31750 . But I have seen numerous issues with Random usage in static fields and similar.

While I think we need to keep our approach for anything having an extension, I also think we need to not make using Quarkus harder than it needs to be.

Granted, listing the packages will be very annoying, granted there might be a small performance hit (but it would need to be measured really), it might help with RSS usage though.

I'm pretty sure this is going to be controversial but we need to have an open discussion about it, find the best compromise for our users and document the decision.

[cescoffier]

Initially, I was against that idea. My reason was that if you want native compilation, you need to do it right; otherwise, you should use JVM. My rationale was (and still is) that we may end up with a native executable using the same amount of memory as the JVM variant (which makes native just a "start fast" feature).

Now, my position has changed. As you said, many other frameworks are using the other default, making native executables easier to produce, even if they may not be as optimized as we would like.

Distinguishing libraries where we have an extension from one where we do not have an extension sounds the right way to ensure we do not lose our current optimizations. With this:

1. Applications only using Quarkus extensions would still be super optimized
2. Applications using libraries may be easier to compile into native, not necessarily optimized as we would like, but it's a first step

We are making the same choice in JVM mode (without knowing it). You can use any library without using an extension. It may not use the build-time principle, but it should work well.

In terms of implementation, yes, that's the annoying part. As you mentioned, the proper way would be to have extensions list all the packages of the managed library. For extension, managing optional parts of the managed library would only register the packages if that part is available (we already do that in some places). I'm not sure we can automate this. I would require extensions to produce a build item for the jar (the whole library) or packages.

Now, the question is, "Should it become the default?" Eventually, I would say yes, but we may want to have a period where this can be opt-in until all the extensions do the work. Otherwise, it could introduce performance (RSS) regressions. Even if/when it becomes the default, we would need to have an opt-out flag for the "hard core" people who do not want to compromise with RSS.

[zakkak]

+1

Having a build item for registering packages for build time initialization sounds like the right way to go. Users could use that build item to manually add additional libraries to the list of build time initialized code making it possible to gradually move from quarkus-core only build time initialization to global build time initialization.

To take this a step further Quarkus should probably start using https://github.com/oracle/graalvm-reachability-metadata for the configuration of the unmanaged packages when possible.

[maxandersen]

+1 on not requiring it for users code or at least be able to easily turn it off.

In past the issue been that no one could come up with a way for us to identify which jars/packages are user code and which are not.

Hence a good start IMO is if we could at least make it easy to turn off on a GAV level maybe?

Or has some stuff changed so we now can detect what is user vs quarkus space?

[gsmet]

@aloubyansky do you think it would be hard to detect jars coming from Quarkus extensions (and so identify the ones that are not properly vetted)?

Because a potentially good approximation would be that we initialize anything that is coming from Quarkus extensions at build time.
And we would have to scan all the jars to determine the packages - and decide what to do if a package is both in an extension jar and in a user space jar.

[aloubyansky]

We could flag dependencies of Quarkus extensions.