-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migration to Java #78
Comments
Or maybe use Kotlin also for the remaining Groovy code by now? |
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. |
I guess you're familiar with Kotest? It has several similar test styles as well.
So just to double-check: Porting from Kotlin to Java? That sounds like a severe step backwards, IMO...
I'd be interested in the details if you can share! |
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.
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. |
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?
Reducing dependencies to a minimum, with a balance of reinventing the wheel, is certainly always a good idea. |
Rewrite the plugin only using plain old Java with minimal dependencies.
The text was updated successfully, but these errors were encountered: