Allow incomplete classpath configuration to be more granular

[galderz]

Is your feature request related to a problem? Please describe.
Having 3rd party libraries define --allow-incomplete-classpath can be very problematic for frameworks such as Quarkus.

When the flag is there, errors start to become more difficult to understand. It would even seem that the native image itself behaves differently enough, that seemingly unrelated errors appear out of nowhere.

Quarkus tries as hard as possible to avoid any 3rd party libraries setting it, but at time some of those are proprietary or closed source, so there's nothing we can do about it.

The worst part of the flag is the fact that it has a global implication.

Describe the solution you'd like.
It would be nice to have an optional way to make the flag not global. That is, find a way to trim the code that is affected by this flag.

For example, could we find an idiomatic way to say: allow these methods/classes/packages to reference bytecode for which classes are not in the classpath. For any other part of the code, throw an error.

Describe who do you think will benefit the most.
Frameworks which depend on GraalVM, e.g. Quarkus.

Describe alternatives you've considered.
We don't see any other alternatives.

Additional context.
Add any other context about the feature request here.
For example, link to the relevant projects, documentation, standards.

Express whether you'd like to help contributing this feature
I'd be happy to implement it once we've found an agreement.

[Sanne]

Describe alternatives you've considered.
We don't see any other alternatives.

For completeness, I'd add that we considered suggesting to deprecate --allow-incomplete-classpath without any alternative. But I'm afraid that might limit adoption and make it much more difficult to achieve compatibility with native images, as we have frequently encountered the need to use such flags, at least temporarily, to be able to make progress in iterative improvements.

Considering that the intent of --allow-incomplete-classpath is to allow incremental progress by temporarily accepting some specific technical debt in a project, we think it makes sense for [some evolved variant of this flag] to limit its impact to the specific need exclusively, and without potentially affecting other code beyond the code which is allowed to do this, most likely leading to unintentionally hiding problems in unrelated code.

[galderz]

For reference, Sanne wrote up some more thoughts about this in this discussion.

[christianwimmer]

PR with a proposed solution: #4305

[galderz]

@christianwimmer #4305 is not a solution for the problem specified above.

Using the nomenclature in #4305, Quarkus would be in the boat of using --link-at-build-time without arguments via the native-image, but we lack the ability to specify which classes/packages we'd want to be linked at run time. An alternative solution that Quarkus goes and specifies all packages+classes --link-at-build-time without mentioning the classes/packages that would need to be linked at run time is simply not scalable.

[zakkak]

An alternative solution that Quarkus goes and specifies all packages+classes --link-at-build-time without mentioning the classes/packages that would need to be linked at run time is simply not scalable.

It looks like Quarkus might end up doing something similar for build time initialization (as discussed in quarkusio/quarkus#42682 and quarkusio/quarkus#48427) which would then enable us to use for --link-at-build-time as well.