Support new GraalVM releases

[sschuberth]

The new GraalVM release changed the versioning scheme to be aligned with the JDK version. To reflect this in a non-conflicting manner, discoapi uses the new name "graalvm_community" (and "graal" for the new "Oracle GraalVM" distribution under the GraalVM Free Terms and Conditions (GFTC) license).

As currently the GraalVM Community Edition name is assumed to be "GraalVM CE X" where X is an integer, this change in the version / name requires some adjustments to this plugin as well.

Here are example responses from the discoapi distributions API call:

    {
      "name": "GraalVM",
      "api_parameter": "graalvm",
      "maintained": true,
      "build_of_openjdk": false,
      "build_of_graalvm": true,
      "official_uri": "https://www.graalvm.org/",
      "synonyms": [
        "graalvm",
        "GRAALVM",
        "GraalVM"
      ],
      "versions": [
        "20.0.1",
        "17.0.7"
      ]
    }

    {
      "name": "GraalVM Community",
      "api_parameter": "graalvm_community",
      "maintained": true,
      "build_of_openjdk": false,
      "build_of_graalvm": true,
      "official_uri": "https://www.graalvm.org/",
      "synonyms": [
        "graalvm_community",
        "GRAALVM_COMMUNITY",
        "GraalVM Community",
        "graalvm community"
      ],
      "versions": [
        "20.0.1",
        "17.0.7"
      ]
    }

    {
      "name": "GraalVM CE 8",
      "api_parameter": "graalvm_ce8",
      "maintained": false,
      "build_of_openjdk": false,
      "build_of_graalvm": true,
      "official_uri": "https://www.graalvm.org/",
      "synonyms": [
        "graalvm_ce8",
        "graalvmce8",
        "GraalVM CE 8",
        "GraalVMCE8",
        "GraalVM_CE8"
      ],
      "versions": [
        "21.3.1",
        "21.2",
        "21.1",
        "21.0.0.2",
        "21",
        "20.3.3",
        "20.3.2",
        "20.3.1.2",
        "20.3.1",
        "20.3",
        "20.2",
        "20.1",
        "20-ea",
        "19.3.6",
        "19.3.5",
        "19.3.4",
        "19.3.3",
        "19.3.2",
        "19.3.1",
        "19.3.0.2",
        "19.3"
      ]
    }

[sschuberth]

Note, running java -XshowSettings:properties -version on the graalvm-community-openjdk-20.0.1+9.1 distribution shows java.vendor = GraalVM Community (like with the previous versioning) whereas Oracle GraalVM shows java.vendor = Oracle Corporation.

[fniephaus]

In addition to graalvm_community, there is also a new graalvm api_parameter in case this integration also likes to support the new Oracle GraalVM distribution. Feel free to reach out to me, happy to help.

[sschuberth]

Feel free to reach out to me, happy to help.

@fniephaus, could you help me understand the (by now) "legacy" GraalVM versioning scheme?

Like, e.g. in "GraalVM CE 17" what does the "17" stand for? Is that the Java language level, i.e. Java 17? And if so, why is there also a parallel "GraalVM CE 11" release if a Java 17 compiler usually can also target Java 11? I.e. what sense does it make to release "GraalVM CE 11" and "GraalVM CE 17" at the same time? Finally, what's 22.3.2 in above's example? The GraalVM release version that's basically independent of the java language version?

Thanks for any insights!

[fniephaus]

Like, e.g. in "GraalVM CE 17" what does the "17" stand for? Is that the Java language level, i.e. Java 17?

Yes, that is correct.

And if so, why is there also a parallel "GraalVM CE 11" release if a Java 17 compiler usually can also target Java 11

Previous GraalVM releases, although built from the same GraalVM sources (e.g. 22.3.0), targeted multiple Java versions. 22.3.0, for example, includes builds for Java 11, 17, and 19.

Finally, what's 22.3.2 in above's example? The GraalVM release version that's basically independent of the java language version?

That's the GraalVM version, which we currently still use to version the GraalVM sources.

Fun fact: technically, GraalVM for JDK 17 and JDK 20 were also built from the same sources (23.0.0). Due to the OpenJDK alignment, however, we've adjusted the versioning scheme so that it no longer includes the GraalVM source version (23.0.0). Instead, GraalVM releases will follow the OpenJDK release calendar. So in September, there is going to be a GraalVM for JDK 21 release.

[sschuberth]

Thanks for your answers, @fniephaus! I have a follow-up question: With the new releases and versioning scheme, how can I programmatically tell which Java language versions are supported for a "GraalVM Community" release? For example, if the API lists

  "versions": [
    "20.0.1",
    "17.0.7"
  ]

is it correct to assume that version "20.0.1" supports all Java language versions <= 20, and version "17.0.7" supports all Java language versions <=17? That is, if I was targeting Java 11, I could choose either version, but if I was targeting Java 19, I could only choose "20.0.1", correct?

[fniephaus]

With the new releases and versioning scheme, how can I programmatically tell which Java language versions are supported for a "GraalVM Community" release?

Java is usually backward compatible, so you're proposal works unless you're users use internal or deprecated APIs. I'm not 100% sure whether this ticket is about the Java version or the JDK version. If it's the latter, then users probably want a JDK 11 (e.g., from the 22.3.2 release) and not JDK 20. Also note that, for example, Oracle GraalVM for JDK 17 is a LTS release while Oracle GraalVM for JDK 20 is not.

BTW, the JDK release notes include this on the compatibility topic:

You should be aware of the content in the Java SE 20 ( JSR 395) specification as well as the items described in this page.
The descriptions on this Release Notes page also identify potential compatibility issues that you might encounter when migrating to JDK 20. The Kinds of Compatibility page on the OpenJDK wiki identifies the following three types of potential compatibility issues for Java programs that might be used in these release notes:
Source: Source compatibility preserves the ability to compile existing source code without error.
Binary: Binary compatibility is defined in The Java Language Specification as preserving the ability to link existing class files without error.
Behavioral: Behavioral compatibility includes the semantics of the code that is executed at runtime.
See CSRs Approved for JDK 20 for the list of CSRs closed in JDK 20 and the Compatibility & Specification Review (CSR) page on the OpenJDK wiki for general information about compatibility.

Hope this helps!

[tanvirp]

This is blocked by foojayio/discoapi#77.

The above issue is already closed as invalid. What does that mean for this issue?

[sschuberth]

This is blocked by foojayio/discoapi#77.

The above issue is already closed as invalid. What does that mean for this issue?

It's not blocked anymore. That's why I've created #35 to resolve this issue.