Does not work on JDK 16 #231
Comments
That is correct. Groovy makes it on the classpath as a transitive dependency of the runner projects. I guess the proper fix consists of
For the tests, the fact that the Java 16 build passes is unfortunate. I don't know if is easy to add a 'cross Gradle version' test run to the build matrix, like 'built with 6, tested on 7, Java 16'. It might be very easy or very hard. |
|
Thanks for digging in this. On your points:
Another solution to that problem would be to have two builds of Gretty 3... |
That was a bit imprecise, rather than getting rid of it, I suggest to move the Groovy dependency from
"Gretty is not forked in a new process": to my understanding, that is partially true. Yes, as in "Gretty the Gradle plugin", Gretty must not have the Groovy dependency, because Gradle already provides one. I do think "Gretty the runner process" is a forked execution without inheriting the classpath of Gradle (see for example I think that approach is much better long-term, and avoids having to meddle with separate Gretty builds and distributions. I'd consider to do it, but first we must have a known-good Gretty release in place. I do not perceive this as urgent. But if done, I'd really like a functioning previous release on official channels just in case this change messes up in some way. |
|
I'm still getting this error (or a similar one) with Gretty 3.0.5, Java 16, and Gradle 7.1, in a multi-module project. My relevant build,gradle source is: buildscript {
repositories {
mavenCentral()
gradlePluginPortal()
}
dependencies {
classpath "org.gretty:gretty:3.0.5"
}
}
apply plugin: "gwt"
apply plugin: "war"
apply plugin: "org.gretty"
...I'm using GWT, which has two modes it can use to test a site -- This isn't terrible for me because I had resolved this in a fork that I build on JitPack, but it is somewhat of a letdown. I was hoping to have an official release at some point that was support-comparable to the hacked-together code I wrote while literally suffering a fever; oh well, I'll keep waiting. If anyone else wants to use my fork to get Java 8-through-16 and Gradle 7 working with the 3.x branch, there's https://jitpack.io/#tommyettinger/gretty/3.0.4.5 . You may need to put JitPack first in the order of repositories checked for your buildscript. |
|
@tommyettinger - we wanted to release 3.0.5 because there were other issues that were fixed. There will be an "official release" supporting JDK 16 - hopefully soon. All of us are doing this in our free time. Your fork doesn't work on Gradle 6 so that's why we haven't used that way of adding support for JDK 16 - the "real" fix is a bit more complicated. Sorry we've let you down. :) |
|
It certainly is complicated... If there's anything I can do to help speed up the process, let me know. It's so odd that Gradle 7 breaks Gretty (and the Android Gradle Plugin), but very little else I've used. The usage I have is a project generator that can enforce using Gradle 7, but until that works with Android I'm not even sure I should be using Gradle 7. |
|
Thanks for offering help! As for Gretty - you're a bit mistaken. Gretty (3.0.5) works totally fine on Gradle 7 - that's how I use it in my project. It also works fine on Gradle 6. In order to support both, we build Gretty with Gradle 6. Unfortunately Gretty uses the Groovy version of the Gradle version it was built with (for now) - that's Groovy 2.5 from Gradle 6. Groovy 2.5 doesn't work on JDK 16. That's the reason JDK 16 is not supported. And that's the reason your fork works - because you build it with Gradle 7. But in that way you break Gradle 6 support. |
|
Wow... that's complicated. Is there some technique Gradle provides to deal with incompatibilities like this? Or is this something that needs to be handled by, say, adapting which Groovy version is used to match the current Gradle version's built-in Groovy? |
|
That's mostly an issue with Gretty as it is written to somehow "bundle" Groovy instead of using the one from the user's runtime. We (or rather @f4lco as always 😄) will just fix that and hopefully the issue will be resolved. |
|
@f4lco I'm seeing this on my system where Groovy version does not match the one bundled with gradle: Is there any way to force to use Gretty to use my version of Groovy instead of the one Gradle comes with? |
|
You didn’t say which version of Gretty you’re using?
|
|
@boris-petrov does not work with This workaround doesn't work on |
|
@lipnitsk can you check back #237? Maybe that gives you new clues, and we might need to re-open that ticket as needed.
If you're feeling adventurous, I also pointed out where to find the toggles for the Groovy version inside Gretty in #237 (comment). PRs are always welcome 😄 Thanks @lipnitsk for the report and your time. |
Running
gradle appStarton JDK 16 on thisbuild.gradlefile in an empty directory leads to:@f4lco - I don't understand what's going on. As I've mentioned before, Gretty seems to use Groovy 2.5.14 for some reason. Obviously that's true because of the error above. My only wild guess is that Gretty uses the Groovy version that the Gradle version that we build with uses - we build with Gradle 6.x which uses Groovy 2.5.14. I don't see where else that version would come from. And also, why doesn't the CI fail?! Any ideas?
The text was updated successfully, but these errors were encountered: