Deprecate support for Java 8 (in fact <11)

[szpak]

Having 1.2.0 released (one day ;-) ) we could consider deprecating the (official) support for JDK <11. As the project uses Kotlin, the syntax is not a big deal, but Java 8 is very old and we could help convince people to migrate. In the first phase, we could just remove JDK 8 build from CI, but keep source/target compatibility with JDK 8, unless some our dependencies are only JDK 11+.

As the java toolchain functionality is available in Gradle, people could still compile their code with JDK 8, if really needed (even if we switch hard to JDK 11).

Feel free to comment (or "vote") here, if you have any strong arguments against that idea (or even if you would like to make a hard switch to JDK 11, not to mention 17 ;-) ).

[vlsi]

If the project is built with target 8, that is fine to me.
It would be sad if the plugin required Java 11 for Gradle execution.

[TWiStErRob]

It would be sad if the plugin required Java 11 for Gradle execution.

Agree, until Gradle drops Java 8 support, all plugin authors (looking at you AGP 😉), should keep that minimum version.

If the project is built with target 8, that is fine to me.

Keeping target 8 is fine, it means the produced JAR will be usable with Java 8 or anyone using target 8 in their builds. At this point it doesn't matter at all which JDK you use, you can even build on JDK 19 as long as your target is 8.

I would like to mention here that there's a common misconception of CI matrixes, really well explained here: https://jakewharton.com/build-on-latest-java-test-through-lowest-java/

[vlsi]

I incline https://github.com/vlsi/github-actions-random-matrix is a better approach for CI matrix.

See https://twitter.com/vladimirsitnikv/status/1623265219383263232

What do you think of switching to a randomized matrix?

[TWiStErRob]

The point of the link is that you don't even need a CI matrix, build the thing once on the latest version, and then run the tests on different JREs. I agree with randomizing parameters after the simplification has been made.

[vlsi]

you don't even need a CI matrix

I'm not sure how are you going to test Windows/Linux without a matrix 😀

[TWiStErRob]

Fair, I'm referring to Java versions... 😅

publish-plugin/.github/workflows/java-versions.yml

Lines 15 to 20 in 54dff4e

	openjdk:
	strategy:
	matrix:
	jdk: [8, 11, 15]
	name: "OpenJDK ${{ matrix.jdk }}"
	runs-on: ubuntu-latest

[ciscoo]

I agree that this plugin should continue to target Java 8 for as long as Gradle continues to support/run on Java 8.

There really isn't anything (IMO) to gain by requiring Java 8+ since most of the gains are beneficial to applications or JVM libraries -- this plugin is neither.

Some gains for the plugin could be switch expressions, record classes, text blocks, and more. But since this plugin is written using Kotlin, you can use the Kotlin equivalent all while still targeting Java 8.

However, I think that this project build itself can certainly require/use more recent versions of Java. This allows tests and anything else to take full advantage all while still remaining Java 8 compatible for the main plugin source.

[TWiStErRob]

@szpak should we punt this to 3.x?

[szpak]

Well, I think we could even close it as "done" once documented in README (I will create a PR). The support is deprecated and building with JDK 8 in 1.x/2.x is not guaranteed (it might be not possible). In addition, it opens a possibility to just drop it (as previously deprecated in the minor release, if needed - although we could also wait for 3.0 if feasible).

[TWiStErRob]

Toolchains allow any combination. And Java 21 only removed Java 7 support! So we have plenty of leeway.

[szpak]

Yeah, Gradle plays very insurancely (?). Maybe they know they have clients using "ancient" (in general mean) Java versions.

I like the approach of Spring or Mocronaut to push users to migrate to the recent versions. The "official" deprecation can be some impulse (as anyway many other Gradle plugins have already switch targetCompatibility - most likely those written in Java). Nevertheless, as you say, we can still support handle JDK 8 (especially using Kotlin).

[TWiStErRob]

as anyway many other Gradle plugins have already switch targetCompatibility

Hmm, I guess I stopped noticing because I've updated all my builds already and also helped some others.

push users to migrate to the recent versions

The difference between Spring/Micronaut and us, is that we're a tiny piece of the (Gradle build) puzzle, while those are in the spotlight and the end product running on production servers. So they benefit greatly from having a newer runtime (safety, performance). The only thing dropping Java 8 at this moment would achieve is annoy some users without the ability to do anything about it (other than updating their build). I think we need to let the big players (e.g. Gradle, AGP, Kotlin) dictate.

Note that as far as I know toolchains allow forward too. So a Gradle build on CI can run on Java 8, while using a JDK 21 toolchain to produce Java 17 class files. It's silly, but you never know what corporations are up to 😅.