Heads up: Upcoming changes in the way GraalVM handles unsupported elements

[Foivos Zakkak]

Hi all,

https://github.com/oracle/graal/pull/8815 is going to switch the default behavior of GraalVM (expected to happen in 24.1, a.k.a. GraalVM for JDK 23) to reporting unsupported elements at runtime instead of build time.

In Quarkus this behaviour is defined through quarkus.native.report-errors-at-runtime which is by default set to false (and we might want to consider deprecating).

According to Vojin Jovanovic this change would only affect applications reaching unsupported elements, like deleted methods/fields/classes, which is not expected to be the case for typical user code.

However, 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. Right now users catch such cases early on since they are reported at build time. With the new default users will instead get an UnsupportedOperationException at runtime.

Note that this is not far from what Quarkus already does with some substitutions, e.g. https://github.com/quarkusio/quarkus/blob/0efd81a42c5e916f040b038921cd725e54528fc1/extensions/jdbc/jdbc-mariadb/runtime/src/main/java/io/quarkus/jdbc/mariadb/runtime/graal/SendPamAuthPacket_Substitutions.java#L20

What do you think about this change? Do you foresee any major issues if we adopt this change? Should we consider switching the Quarkus default even before GraalVM for JDK 23 comes out?

FWIW: It looks like we will be able to keep the current behaviour if we want to by using the experimental option `-H:-ReportUnsupportedElementsAtRuntime` option

Kind regards

--

Foivos Zakkak
Senior Software Engineer, R&D Product Middleware
Red Hat
7B4069D929BAAE91C0B3220A0846BFD103F04EA1