On 06.12.23 00:32, Owen Thomas wrote:
This matrix is just doing my head in, because all I can gather from
the page disclosed is a mechanism - I don't understand why the
mechanism needs to exist in the first place.
because gradle uses kotlin and groovy as the config file format
language, languages which are implemented on top of java (its more
complicated but this is the simple version). They will always lack a bit
behind in supporting the latest java version. Gradle has to wait for all
dependencies to be ready before it can claim in a release that it
supports Java X.
The exact same thing happens in NB, gradle 8.5 was released too late to
be tested and integrated into NB 20, so it ships with gradle 8.4. NB 21
will whip with whatever is ready when the release candidate phase starts.
btw upgrading gradle in NB is relatively easy, you can do it yourself,
open a PR and you have a NB dev build which includes a jdk 21 compatible
gradle release, example: https://github.com/apache/netbeans/pull/6553
Now lets compare this with other build tools like apache maven or ant,
they use XML as their file format. The last spec change to XML was in
the year 1820 (estimated). I just tested it, and even a 14 years old
release of maven (2.1) works fine on JDK 21 (but please don't try this
at home, running end-of-life network connected libs is not a good idea -
this was just an experiment to proof a point). This problem essentially
doesn't exist with maven and ant.
hope this helps,
-mbien
I don't think the version of a build tool should need to be matched
with a version of the JVM - but this is indeed probably merey my
ignorance of the justification for this necessity speaking. Is there a
page that informs my ignorance?
On Wed, 6 Dec 2023 at 03:23, Bernd Michaely <i...@bernd-michaely.de>
wrote:
https://docs.gradle.org/current/userguide/compatibility.html
On 04.12.23 01:24, Owen Thomas wrote:
>
> Is there a page I can read that outlines how Gradle will work with
> Java in the future? This stuff is giving me a headache.
>
