graalvm-reachability-metadata
graalvm-reachability-metadata copied to clipboard
Introduce `tested-java-versions`?
Currently, we assume that all metadata works on all releases of GraalVM. Now that GraalVM for JDK 22 is out, there is unfortunately a first incompatibility: undertow-core
in version 2.2.19.Final
pulls in org.wildfly.common
in version 1.5.4.Final
which still depends on internal Native Image API and no longer works on JDK 22+. To work around this particular issue, we have force-upgraded org.wildfly.common
to version 1.7.0.Final
(even though the tests pass, undertow-core
needs to upgrade its org.wildfly.common
dependency).
Since we have no intentions to break existing metadata, we somehow need to be able to specify "this version of the metadata works with these GraalVM releases / Java versions". One way to do this is to add a new tested-java-versions
property to the entries in the main index.json
for a maven artifact. For undertow-core
, for example, it would look like this if we assume that version 2.X.X.Final
upgraded org.wildfly.common
to version 1.7.0.Final
:
[
{
"latest": true,
"metadata-version": "2.X.X.Final",
"module": "io.undertow:undertow-core",
"tested-versions": [
"2.X.X.Final"
],
"tested-java-versions": [
"17",
"21",
"22",
"23"
]
},
{
"metadata-version": "2.2.19.Final",
"module": "io.undertow:undertow-core",
"tested-versions": [
"2.2.19.Final"
],
"tested-java-versions": [
"17",
"21",
]
}
]
This means that 2.2.19.Final
will only ever be tested on 17
and 21
, while the metadata for 2.X.X.Final
will also be tested on 22
and 23
. Note that, while 23
is not GA yet, we will test against an EA build. For convenience and backwards compatibility, Java 17+ is assumed when tested-java-versions
is not specified.
To optimize the CI load, we propose that we
- test on all specified Java versions when testing changed metadata
- test only on the oldest and the newest specified Java versions when testing all metadata
Moreover, we could also use this additional information to provide users with a warning when they build applications with dependencies that require metadata not tested on the Java version they are currently using, or not inject metadata for incompatible Java versions, or even fail the build (if we know the dependency needs metadata to function).