Bump minimum required JRE to 11?

[nedtwigg]

At some point within the next 20 years, it would make sense to bump our minimum JRE from 8 to 11. It might even make sense right now, though I'm in no hurry.

Things which are held back by our JRE 8 compatibility:

• we are on JGit 5.13, which is still receiving patch updates, but we have missed 6.0, 6.1, 6.2, 6.3.
  • 6.3 in particular could help with #710

Things which are enabled by our JRE 8 compatibility

• GJF pre-1.15.0
• PalantirJavaFormat pre-2.10.0
• Eclipse pre-4.21
• Sortpom pre-3.2

Maybe other stuff. I don't think losing these older versions is catastrophic (and of course the old versions of Spotless don't go away either).

Please thumbs-up if you'd like a bump, thumbs-down if you don't.

[simonbasle]

I would prefer that change to be deferred a bit longer, as I'll still need to produce Java 8 artifacts for a few years. Of course I should probably consider Gradle's toolchain feature in order to build Java 8 artifacts while running with a JDK 11+, but that's a migration I still need to evaluate and which will take time 😞

unless you would be able to continue delivering a Java 8 compatible Spotless in parallel to the Java 11 compatible version? If the only difference is the Java baseline + the JGit dependency + the features / changes that depend on JGit 6.x, perhaps this is achievable?

[nedtwigg]

continue delivering a Java 8 compatible Spotless in parallel to the Java 11 compatible version

The old versions of Spotless won't go away, but they will not get new features or bugfixes. We will not have parallel development.

Most of the formatters we support already require Java 11 in their latest versions. So it is already the case that if you are stuck on Java 8, the formatters that Spotless delegates to are not getting new features or improvements.

[Emkas]

Well, there always will be a legacy code and someone who doesn't want to go higher.

Even if I myself stay on a J8 for many reasons, I don't think this should be a reason to stay in place for any other software. I'd say that the more software will update to Java 11, the sooner our legacy code base will be updated to it.

[nedtwigg]

Spotbugs gives bad warnings on Java 8. Because of that we only run it on Java 11, but we should redo this commit after we drop Java 8. https://github.com/diffplug/spotless/pull/1511/commits/4aa3b7e0f460eaa7a7c329a7868e71060151c95b

[nedtwigg]

I think it's time to do this. I'm doing it in two steps.

1. Keep running on Java 8, but yell at users to upgrade to 11 (and tell them how without affecting their end users) #1514
2. Once that has been released, actually upgrade to 11.

If you have submitted a lot of PRs to Spotless and this upgrade path is not okay with you, speak up soon and I can wait longer. But I'd like to do the upgrade gracefully (yell at users and tell them how to upgrade), and that means we need to do this early enough for the yelling release to be the latest available for a little while.

[nedtwigg]

Part 1 published in plugin-gradle 6.14.0 and plugin-maven 2.31.0.

[eirnym]

This is quite sad that you bump your plugin to java 11.

Additionally, while technically you can build a gradle plugin with Java 11, or even Java 17 bytecode, Gradle by default use Java 8 bytecode.

Additionally, many gradle plugins still support compatibility with Gradle 6.x (at least) and this can be built only with target Java8.

Now, to have Java 8 compiled, I have to write a plugin for my plugin to configure spotless plugin properly and my plugins section will look like below, which is a crappy, but I have to do this way.

plugins {
    id("com.gradle.plugin-publish") version "1.1.0" apply false
    if (JavaVersion.current() >= JavaVersion.VERSION_11) {
        id("com.diffplug.spotless") version "6.14.0"
    }
}

Why do I build using Java 8? I have integration tests running on each build, and they involve execution of Gradle tasks from version 6.0 to the current one. Using Java 11 I can't run any gradle below certain point.

I understand you won't revert your change, just informing you how this change affects many gradle plugins which use spotless for a quality control.

[nedtwigg]

Sorry for the adverse effect, and thanks for communicating it :) Spotless 6.13.0 is still available, and most of the formatters we wrap don't support Java 8 anymore anyway, so if you're stuck on Java 8, there won't be much difference between 6.13.0 and future versions of Spotless anymore.

integration tests running on each build [that need Java 8]

One way to solve this is to run your build on Java 11, and use Java 8 as the runner for your integration tests.

https://docs.gradle.org/current/userguide/toolchains.html#specify_custom_toolchains_for_individual_tasks

Bumping to 11 here is an easy choice because of JGit. Spotless was over a year behind, and other plugins that use JGit (e.g. org.ajoberstar.grgit) have upgraded to JGit 6 to get the performance improvements and new features that JGit has shipped. It is currently impossible to use Spotless in the same build as those plugins.

6.13.0 is a great Spotless, nothing wrong with continuing to use it for a long time :)

[eirnym]

My matrix include Java 8, 11, 17 and 19, so it's not as easy as "freeze spotless plugin"

[eirnym]

It's quite easy to support dependencies which require java 11, 17 and so on as long as Gradle has still the same or almost the same API.

I've done in my plugin using following trick:

• I build with Java 8 and 11 (to test gradle 6.0-current)
• I build with java 17 release version

for a dependencyies which requires java 11 (currently it's AGP 7) and java 17 (upcoming AGP 8), I have a conditional inclusion in settings.gradle.kts and build.gradle.kts. Thus I have java 8 byte code, which uses proper API from AGP 7. nothing is breaking as long as my plugin is used as intended.

In your case for tests for google java formatter, it's easy to include even tests, adding a condition, that they'll run on java with number at least 11 or 17 (or whatever you need).

[eirnym]

PS: I don't know how you handle dependencies for Maven as I don't use it. I know that Gradle plugin will work flawlessly