Replies: 3 comments 10 replies
-
I'm pretty sure there are JDK 11 versions for M1. I checked the adoptium page, and shouldn't "aarch64" be the correct package for M1? https://adoptium.net/de/temurin/releases?version=11
I believe you're mixing multiple things here. One thing is the installed JDK version on your system. If this installed JDK version is older than the version you're trying to set this will not work. If you install a more recent JDK version this variable ensures the code is compiled according to the rules of Java 11 (See this stackoverflow post for the difference of source and target version). So chances are you can install a JDK 17 and compile the code just fine. Another thing that needs to be considered is the installer. Currently we bundle a JDK 11 with the installer, that of course would also need to be updated accordingly. When it comes to language features I would be in favour of upgrading. Stuff like "records" is nice for tuple like structures without requiring lombok for example. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting that there's a 11 version for mac arm, I don't understand how that works with the openjdk ticket saying it's a jdk 17 thing. I understand gradle needs java, but I don't see why the java gradle runs for itself needs to be the same that's used to compile and run the given project. I mean, I understand that might be the decision they made, but seems not a great design decision by gradle. |
Beta Was this translation helpful? Give feedback.
-
|
Java Version comes into play in a few places:
The very latter is something we can swap out for our own bundled JDKs. If there is a Mac JDK that we can bundle that is not run on an emulator, that is something we could readily swap out. |
Beta Was this translation helpful? Give feedback.
-
There is but we have to distribute 2 mac installers then, we can't just swap it out. |
Beta Was this translation helpful? Give feedback.
-
|
Why can't we just swap it out? We used to bundle our own, the config looks similar, the option is "use a pre-created JRE bundle": |
Beta Was this translation helpful? Give feedback.
-
|
@DanVanAtta I mean we can swap it out, but "older" devices running macOs are still using Intel processors (x86 architecture) and we probably want to keep supporting those. The newer ARM JDK will most likely not run on x86 |
Beta Was this translation helpful? Give feedback.
-
|
Good question about the ticket. For the most part it should be possible to just change the compiler to generate different machine code, but maybe they backported some code changes? Regarding the gradle java thingy: I agree that this seems like a poor design choice, but I honestly can't think of a language ecosystem that has its version managed as well on a project basis. For python things like virtual environments exist, but you kinda have to create them on your own for specific projects to my knowledge. C/C++ doesn't even have a proper widely adopted dependency management system and if your compiler doesn't support a certain feature yet you're out of luck. JavaScript also requires you to have a recent nodejs version/hope the the browser supports it. |
Beta Was this translation helpful? Give feedback.
-
|
Now that we are a year later.. JDK 17 is pretty attractive for its multi-line strings. I'd be happy to see a JDK version upgrade. |
Beta Was this translation helpful? Give feedback.
-
We're currently on Java 11. Should we update?
I think one downside of this version is on Mac, we don't have an M1 native version, so it runs in emulation (and thus much slower).
If we want to update, is there something more to do than changing
JavaVersion.VERSION_11in build.gradle? When I tried setting something more recent, I get a build error...Beta Was this translation helpful? Give feedback.
All reactions