[GR-43837] Enable --report-unsupported-elements-at-runtime by default and deprecate the option.

[graalvmbot]

Libraries can freely remove --report-unsupported-elements-at-runtime from their native-image.properties files. If these libraries are used with previous GraalVM versions --report-unsupported-elements-at-runtime should be added to the command line (ideally by the framework).

[zakkak]

Hi @vjovanov, does --link-at-build-time suffice to keep the old behavior? Perhaps it would be worth mentioning how to bring back the old behavior in the changelog and the deprecation message.

[vjovanov]

@zakkak the previous behavior can be kept with -H:-ReportUnsupportedElementsAtRuntime but I would not recommend that for end users. This mode should not ever affect the end users as they are free to write any type of code. It should only be used for internal testing to guarantee that certain elements obviated by substitutions can never be reached (without using reflection).

I would not connect this to link-at-build-time as link-at-build-time is something that can be fixed by end-users by providing regular jars. Here, if a library reaches some deleted element it can hardly be fixed by the user.

[zakkak]

@zakkak the previous behavior can be kept with -H:-ReportUnsupportedElementsAtRuntime

Oh, it's just the API option being deprecated not the internal one. I see.

but I would not recommend that for end users. This mode should not ever affect the end users as they are free to write any type of code.
[...snip...]
Here, if a library reaches some deleted element it can hardly be fixed by the user.

If I get this right, you mean that user code should never result in an unsupported element exception. In that case what's the difference for them either way? What's the benefit of changing this default?

Furthermore, wouldn't it be preferable for the build to fail and prompt the user to report the issue instead of letting it build and result in a potential unexpected crash at runtime?

[vjovanov]

Well, the user code that does not use reflection should not be able to reach elements marked as @Delete. When using reflection users can reach anything, and in these cases we need to fail at run-time. The reached elements will anyhow fail at run-time with a fatal error.

So this is for users that reach @Delete elements by accident via reflection so their build doesn't fail. For the authors that use reflection they should just use the -H:-ReportUnsupportedElementsAtRuntime flag in their tests.

[vjovanov]

This flag is also historic from the time when Native Image did not support many things. Now, Native Image does not support only run-time class definition and a few other details. In all those cases we will throw an UnsupportedOperationException so no need for build-time failures.

[zakkak]

Thanks for the info @vjovanov.

FWIW doing a quick search in the Quarkus repository I see multiple uses of @Delete, which makes me believe that it might not be that difficult for Quarkus users to reach an element that is being marked as @Delete by Quarkus. I will bring this to the attention of the Quarkus community.

Update: FTR the email requesting feedback from the Quarkus community is https://groups.google.com/g/quarkus-dev/c/v5jLzl6cwuE

[zakkak]

As pointed out by @vjovanov this PR results in a number of tests in the Quarkus CI job to fail (see https://github.com/oracle/graal/actions/runs/8819845538).

Looking into the failures I see that they are triggered by the deletion of classes that depend on other classes not present on the classpath.

For example DeleteFullTextLucene.java registers
FullTextLucene for deletion which depends on IndexFormatTooOldException, used here.

So my understanding is that GraalVM tries to load the FullTextLucene class in order to go over its fields, constructors, and methods) but fails because it's not on the classpath...

I recall raising an issue about @Delete and @Substitute requiring all dependencies to be present but can't seem to find it know...

A potential work around in Quarkus would be to require all dependencies of @Deleted and @Substituted classes to be present at build-time, even though the app doesn't actually use them... The main drawback of this is that it might hide cases were the code we want to make unreachable is still reachable and due to the class being on the classpath we don't notice it. Note that Quarkus build time initializes everything by default and uses --link-at-build-time.

I wonder if there is any way to have GraalVM achieve its goal without having to load the class, e.g. by having a "trap" that catches any call or field access to the @Deleted class.

[vjovanov]

I used JVMCI to get the class information and we seem to be good:

https://github.com/oracle/graal/actions/runs/8896343413

Thanks @zakkak!