Define minimum JDK requirement for Jakarta-enabled Gretty

[f4lco]

While Jakarta-enabled Tomcat 10 will support Java 8, this is not the case with Jetty 10, which will require at least Java 11 to run. This problem surfaced in #159:

Especially the minimum JDK version would require further discussion. With the state in this PR, Gretty requires all users to use Java 11 at a minimum, although Tomcat 10 only requires 8+. I can only guess how many users would be impacted. If one were to change that, there are two challenges: it requires refactoring, because the "gretty" module can no longer depend on "jetty-util", and changes in packaging, such that there are two Gretty variants, one of which supports only Tomcat and JDK 8+, and another, which ships Tomcat and Jetty connectors and supports JDK 11+.

Refactoring requirements are probably modest, because only a couple of classes around JettyScannerManager are affected. @boris-petrov weighed in on the packaging requirements:

As for the packaging part - I'm not sure you're right there. If Gretty doesn't use anything from Jetty at build-time (so JDK 11 is not required at build-time) I guess it would work on JDK 8 too (because Jetty 10 would be a runtime-only thing so someone using Tomcat 10 won't need JDK 11). I'm not sure I'm correct in this though.

The statements would be true if only some kind of runtime bug occurred with JDK 11. However, there is a build-time dependency on JDK 11 because of changes in bytecode version. Attempting to build Gretty with Jetty 10 dependencies on Java 8 results in the following error:

What went wrong:
Execution failed for task ':libs:gretty:compileGroovy'.
org/eclipse/jetty/util/Scanner$BulkListener has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

In summary, we cannot build on JDK 8, because Jetty dependencies have a more recent bytecode version. Vice versa this rules out JDK 11 as build system, because it cannot cater JDK 8 clients (runtimes).

TBD:

• What should be the minimum required JDK version for Gretty?
• If that is 8, determine follow-up tasks for refactoring.
• If that is 8, adjust deployment options.

[boris-petrov]

So, my idea was that if via this refactoring we manage to remove all build-time dependencies on Jetty (this is what you're talking about, right? The thing that will be "modest" of scope?) then someone using JDK 8 and only running Tomcat 10 will not have any problems. Is that so or not? I didn't completely get that.

If that is the case and you or someone else is willing to do that refactoring, then all is fine. That's not even something that has to be done soon given that this Jakarta stuff is probably not going to be released as stable any time soon.

If that is not the case (or no one has the time for the refactoring work) and Gretty won't work on JDK 8 if Jetty 10 is in the picture in some way then I suggest we drop JDK < 11 support and that's it. We don't want to support 3 different builds (Jetty/Tomcat 9; Tomcat 10; Jetty 10) for sure. Anyways people should be moving away from JDK 8... they've had years to do that. :smile:

[f4lco]

So, my idea was that if via this refactoring we manage to remove all build-time dependencies on Jetty (this is what you're talking about, right? The thing that will be "modest" of scope?) then someone using JDK 8 and only running Tomcat 10 will not have any problems. Is that so or not?

I'm not entirely savvy around bytecode versions either, but my understanding is the current:

• A user wanting Tomcat 8 with Java 8 will also require a Gretty version compiled with Java 8.
• A user wanting Jetty 10 with Java 11 will require a Gretty version compiled with Java 11.

Both statements probably hold true because of conflicts between the supported bytecode version of Java releases and supported Java versions of servlet containers. Conversely, if JDK 11 built Gretty, that resulting bytecode cannot be consumed by JDK8. If JDK 8 built Gretty, it'll fail to link against Jetty 10 dependencies built with a more recent version of Java. To my believe it's mutually exclusive and therefore not possible to appease those constraints in a single artefact:

Build JDK	Test Containers	Artefact Qualifier	Used by
JDK 8	Tomcat 10	"gretty-jdk8"	JDK 8 onwards
JDK 11	Tomcat 10, Jetty 10	"gretty-jdk11"	JDK 11 onwards

So in total there are three steps for rolling that "flavour" of Gretty for Java 8: refactoring, such that Jetty's build time dependencies are removed when compiling with JDK 8; a separate test step in the CI pipeline, such that JDK 8 only test Java 8 capable servlet containers; and finally a new deployment artefact, which carries an additional qualifier, to package classes with different bytecode versions into different JARs.

I hope all of this makes sense. Maybe it's a lot of fuss about things which we may not need / decide against.

[boris-petrov]

If JDK 8 built Gretty, it'll fail to link against Jetty 10 dependencies built with a more recent version of Java.

The question is what dependencies are these. Are Jetty's JARs used at Gretty-configuration-time? If so, we can remove that (if it's not too difficult). Are Jetty's JARs added to the runtime classpath when using Tomcat? If so, we can remove that too. What other kind of "link failure" are you referring to?

Also, I think Gradle has the option to fork a new JVM for tasks and perhaps use a different Java version/JAVA_HOME? If that is indeed so, people could use JDK 11 only for running Gradle and configure it to use JDK 8 for compiling their code and running Tomcat 10 via Gretty (because, for example, their production code must run on JDK 8). So JDK 11 would only be a development-time requirement. If that is possible, I think it won't require changes in Gretty and we can safely just require JDK 11 for Gretty 4 and call it a day?

[f4lco]

Right now it's fairly difficult for me to see if my concerns are valid and if I can get them across properly for you to understand, or alternatively if you already fully understand problem and solution space, but I fail to get that.

However, that's not of much importance - we need to find a way to settle the requirement (JDK 8 compat yes or no), and an implementation may follow. I've seen many times that new approaches arise or believed-to-be-working ones unexpectedly fail while actually trying to accomplish a certain goal.

One interesting data point could be the The State of Developer Ecosystem 2019 survey by JetBrains. According to their numbers a whopping number of 83% of users still run Java 8.

[boris-petrov]

Well, I don't think any of us want to support 3 Gretty versions (we're having difficulties even with 1) so if we can't find a way to support JDK 8 for both Tomcat 10 and Jetty 10, then we go with JDK 11 and that's it. :)

@javabrett, @henrik242 - do you have any opinion on this?

[henrik242]

I'm fine with requiring JDK11 for Gretty 4. I'm on JDK14 for most of my work related projects anyway. JDK8 users can stick with an older Gretty version.

[boris-petrov]

I believe we settled down on requiring JDK 11 for Gretty 4 so this issue can be closed. Thanks!

[f4lco]

Indeed, thank you @boris-petrov 👍

[tommyettinger]

I'm fine with requiring JDK11 for Gretty 4. I'm on JDK14 for most of my work related projects anyway. JDK8 users can stick with an older Gretty version.

This is fine as long as older Gretty versions are compatible with the current Gradle. I believe this would require backporting (at least) #210 to the 3.x line, because Gretty 3.x won't work with Gradle 7 without that PR. It's very frustrating that Gradle 7.0 is needed to use Java 16, and also breaks so many plugins. My situation is that I make a Gradle project generator, https://github.com/tommyettinger/gdx-liftoff , that is meant for new users of a library (libGDX) to get set up without needing to be familiar with a complex Gradle system. It's common that new users download the most recent version of Java (which is currently 16), it doesn't work with the current Gradle, and they downgrade to a version that does work, which is typically... Java 8. Java 8 is still only "mostly supported" by Android and GWT (Google Web Toolkit), both common targets of libGDX projects; I use Gretty as a way to host the GWT site locally during development. As @f4lco noted on the JetBrains survey, and repeated for 2020, the majority of Java developers use 8. There are too few features added in 9 and later to justify the problems that just keep showing up in newer versions, like the inexplicable changes in NIO and how Java 16 breaks Gradle's incremental compilation by default. I still feel like I should support Java 16 as best I can because new users will likely have it, but if that means Gradle 7, then I have to upgrade to Gretty 4.0.0 (unless #210 is backported), and that means I lose compatibility with Java 8. If there's some way around this using toolchains, that might be a good solution.

[boris-petrov]

@tommyettinger - thank you for the comment! I'm glad to tell you that we do support Gradle 7 in Gretty 3 even right now. Version 3.0.4 works fine on Gradle 7 and (I guess) Java 16. The PR that you mentioned, as well as many, many other changes, have been backported. So there is no need for any changes on your side. :)

P.S. beside upgrading Gretty, of course. :smile:

[tommyettinger]

Hm, I may be finding a different issue then. I'll post it in a separate issue, or an existing one if I can find the same problem.

EDIT: OK, I think I understand what you meant. 3.0.4 works on Gradle 7 but does not work with multi-module projects (because PR 210 was merged after 3.0.4 was released). It should work with multi-module projects whenever another 3.x release occurs, since 210 is merged now. I'll hold off on any updates for multi-module projects to Gradle 7 for a while, it isn't out yet anyway (as far as I can recall).

[boris-petrov]

Ah, yes, sorry, this PR was merged after the 3.0.4 release, yes. We'll release a 3.0.5 soon I hope to fix that issue too. And yes, Gradle 7 is not out yet, only an RC.