Comments (9)
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
.
from foojay-toolchains.
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.
from foojay-toolchains.
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!
from foojay-toolchains.
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.
from foojay-toolchains.
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!
from foojay-toolchains.
This is blocked by foojayio/discoapi#77.
from foojay-toolchains.
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?
from foojay-toolchains.
This is blocked by foojayio/discoapi#77.
The above issue is already closed as invalid. What does that mean for this issue?
from foojay-toolchains.
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.
from foojay-toolchains.
Related Issues (20)
- error... reported HOT 3
- 0.4.0 version doesn't work anymore
- Error resolving plugin HOT 1
- class o.g.a.i.p.DefaultProject_Decorated cannot be cast to class o.g.a.i.Settings HOT 5
- Improve crafting release notes for new plugin releases HOT 1
- Plugin usage behind artifactory proxy HOT 2
- Plugin should gracefully handle wrong application to a project instead of the settings
- Update Plugin Portal page to reflect that this plugin has to be applied to an settings file HOT 1
- Better handling for broken connection to Foojay backend HOT 11
- Unresolved reference: toolchains HOT 3
- How to know what distributions are available? HOT 1
- Requesting a Java 22 toolchain fails with a strange error HOT 4
- Fix flaky tests \ Improve FoojayApiTest HOT 3
- Add wrapper-upgrade-gradle-plugin
- Add a retry mechanism for communicating with the Foojay back-end
- can not resolve plugin artifact .foojay-resolver-convention in Oracle Linux HOT 1
- Please maintain a changelog or GitHub releases HOT 3
- Support declaring expected checksum
- Add Gradle JVM vendor for Liberica NIK
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from foojay-toolchains.