Make plugin compatible with Java 8

[Vampire]

Now that the modularity plugin is no longer auto-applied, there is not really a reason to not support Java 8 which still is the minimum version all supported Gradle versions support.

[xzel23]

I know I'm late (just stumbled over this), but isn't the fact that the plugin is not needed on Java 8 (because JavaFX is included in Java 8) reason enough not to add workarounds for that version?

[Vampire]

Not at all.
Don't confuse the Java version Gradle is run with the Java version used for the project.
You can user Java 8 to run Gradle while using JDK toolchains feature to build a Java 21 (or whatever other supported verison) project.
Currently this plugin requires Gradle to run with Java 11 which was ok when auto-applying the modularity plugin as that also required Gradle to run with Java 11 to work.
But as that plugin is no longer auto-applied, there is not really a reason to not support Java 8, thus this PR.

[xzel23]

I disagree. There are plenty of reasons not to make the plugin compatible with Java 8, and this has nothing to do with Gradle toolchains:

• First of all, your change makes the code less concise and harder to maintain.
• Every future change would have to be Java 8 compatible, making life harder for developers.
• Java 8 is a mainly unsupported version of Java, premier support from Oracle ended more than two years ago, even Java 11 has already reached EOL. Extended support is for companies that can for whatever reason not upgrade.
• Keeping the plugin compatible with Java 8 slows down development.
• OpenJFX does not even support JavaFX 8, and no current JavaFX release supports running on Java 8.

So if your only reason to add Java 8 support is that it can be done, better fork the plugin and create a Java 8 compatible release than make life for other developers harder. You can even add Java 6 support if you feel like it.

Or a Java 8 compatible branch can be added where bugs can be fixed. But please don't do this to the main development branch.

I would rather see developers focus on other tasks, like supporting Windows on ARM, than having to make sure every new line of code is compatible with a Java version that got its last public update six years ago and is a security risk for people still using it. And yes, I know some vendors still provide updates, you can even still get Java 6 updates, but that should be of no concern for the future development of this plugin.

[kevinrushforth]

I also see no reason to make this change. In addition to the points mentioned above, gradle 9 will require JDK 17 as a minimum, so you won't even be able to run the latest gradle on Java 8 before long.

[Vampire]

There are plenty of reasons not to make the plugin compatible with Java 8

Name me one that is objectively valid and not just your opinion or plainly wrong. ;-)

First of all, your change makes the code less concise and harder to maintain.

If at all, then only marginally in maybe 2 spots.
The PR mainly replaces List.of by Arrays.asList
and var by explicit types (mainly in places where an eplicit type is anyway better and clearer, thus increasing maintainability).

Every future change would have to be Java 8 compatible, making life harder for developers.

Not really that much harder, the codebase is very small and almost no API or features of newer Java versions are used anyway and it is unlikely that using them in the futuer will win much. And should that really be the case, it can be switched back to requiring a newer Java version any time but hopefully is not.

Java 8 is a mainly unsupported version of Java, premier support from Oracle ended more than two years ago, even Java 11 has already reached EOL. Extended support is for companies that can for whatever reason not upgrade.

Please do not spread this non-sense but research first.
Yes, premier support by oracle for both has ended.
That extended support is available at least until 2030 is not even the argument.
Oracle is since many years not the authorative that deines when support ends or does not end, only for their distributions that they provide or sell.
Temurin for example - which is probably one of the most used JDKs out there - had its latest Java 8 release on 23.01.2025 so less than a month ago.
Amazon Coretto - another one of the most used JDKs out there - had its latest Java 8 release on 21.01.2025.
That is not what I would call "unsupported", quite the opposite.

Keeping the plugin compatible with Java 8 slows down development.

I could not imagine how that could be true.
Maybe if you use a text editor instead of an IDE and don't remember which code is Java 8 compatible and which not.
But under normal circumstances, how should that slow down development?

OpenJFX does not even support JavaFX 8, and no current JavaFX release supports running on Java 8.

Again!
JavaFX 8 is irrelevant.
Whether JavaFX supports running on Java 8 is irrelevant.
What this PR does is making the plugin compatible to run on Java 8.
Java 8 is still the lowest Java version that is supported for running Gradle.
Restricting the Java version a plugin can run on without good reason is just enforcing unnecessary limits on users, making executing builds that use the plugin unnecessary harder.
If some library is used that requires a newer Java version, fine.
If some other plugin is applied that anyway requires a newer Java version like it was before, fine.
But just to use 2 or 3 new API methods and one new language feature that do not really make the code any better or more maintainable is just unnecessary restriction.

You can even add Java 6 support if you feel like it.

For what reason?
Gradle does not support running on Java 6, so making a plugin compatible with Java 6 is pointless.
Supporting what the supported Gradle versions support on the other hand does not make anyones life harder, but the life of the users of this plugin easier by not putting unnecessary restrictions on them.

Please stop being polemic.

I'm not doing this PR "because it can be done", but "because it makes sense" and because it makes the lifes of the plugin users easier.

I'm also not clear why you at all argumenting.
You are neither an author, nor maintainer of this plugin, not even a contributor.
Maybe you should stop arguing in the name of the maintainers of this plugin and let them speak for themselves.
Like any PR that was ever posted to any FOSS project, it is an offer that the maintainers can accept or reject like they prefer.

that got its last public update six years ago and is a security risk for people still using it.

Again, please stop spreading these inexpressibly fake news.
This is just non-sense unless you count less than a month as six years.

[Vampire]

gradle 9 will require JDK 17 as a minimum, so you won't even be able to run the latest gradle on Java 8 before long.

That might be the plan, but plans change.
If in Gradle 9 the support for Java <17 really is dropped (wouldn't be the first deprecation that was delayed several releases),
and this plugin only supports Gradle 9+,
then it is the right time to drop Java 8 support.

But as long as Gradle <9 is supported, it is best for compatibility and usability if plugins support the lowest Java version that is also supported by the lowest supported Gradle version which is Java 8, especially as it does not really cost anything to do so.

[kevinrushforth]

Ultimately, this will be up to @abhinayagarwal or @johanvos to decide whether to accept this PR. I don't see any real benefit in doing this, but maybe they will.