Migration to Java

[britter]

Rewrite the plugin only using plain old Java with minimal dependencies.

[sschuberth]

Or maybe use Kotlin also for the remaining Groovy code by now?

[britter]

Ditching Groovy for Kotlin is an interesting idea. I really love the expressiveness of Spock tests. But Spock is the only reason Groovy is in my stack everywhere.

My ultimate goal is to move the plugin to https://gradlex.org and we have the convention to have all plugins implemented in Java. That's why I want to port this one to Java as well.
The reasoning behind this is that we avoid issues with Groovy / Kotlin language version incompatibilities.

[sschuberth]

I really love the expressiveness of Spock tests. But Spock is the only reason Groovy is in my stack everywhere.

I guess you're familiar with Kotest? It has several similar test styles as well.

we have the convention to have all plugins implemented in Java. That's why I want to port this one to Java as well.

So just to double-check: Porting from Kotlin to Java? That sounds like a severe step backwards, IMO...

The reasoning behind this is that we avoid issues with Groovy / Kotlin language version incompatibilities.

I'd be interested in the details if you can share!

[britter]

So just to double-check: Porting from Kotlin to Java? That sounds like a severe step backwards, IMO...

I don't think that Kotlin or Java is a step forward or backward in either direction. Language selection should depend on the requirements. For GradleX we decided to use Java to have the least friction for users.

I'd be interested in the details if you can share!

There's not a lot to share. Let's say you build your plugin against Kotlin 1.9.x and you use a language feature that's not available in 2.x anymore. Once Gradle moves the Kotlin language level to 2.x the plugin build on 1.9.x won't work anymore. Since Gradle is implemented in Java and Java is generally pretty backwards compatible, it's less likely to run in these kinds of issues. This is also the reason why we try to avoid to have any dependencies in GradleX plugins. This can very easily cause problems, see gradle/gradle#19457.

[sschuberth]

Once Gradle moves the Kotlin language level to 2.x the plugin build on 1.9.x won't work anymore.

Is that so? I mean, in the end it all gets compiled to JVM bytecode, and that's all what Gradle "sees" when executing a plugin, or?

This is also the reason why we try to avoid to have any dependencies in GradleX plugins.

Reducing dependencies to a minimum, with a balance of reinventing the wheel, is certainly always a good idea.

[sschuberth]

I don't think that Kotlin or Java is a step forward or backward in either direction. Language selection should depend on the requirements. For GradleX we decided to use Java to have the least friction for users.

I've seen that discussion on Slack, but I want to share another perspective: With Gradle pushing Kotlin DSL, I doubt that migrating from Kotlin to Java would attract more contributors to this plugin. On the contrary, as Java feels so extremely verbose compared to Kotlin, I myself would not want to contribute to this project if it was written in Java.