It turns out we did bump our minimum JRE for server as well as dev tools to 11 late last year: https://github.com/gwtproject/gwt/commit/0286d6ff3dd19d5a0221a133406f967c88727624. This also means that zero HEAD-SNAPSHOT builds have been tested since then by anyone requiring Java 8 - which does at least suggest this might be a niche issue.
Restoring Java 8 compatibility isn't impossible at this point, but we are using "new" (added in 2017) methods, such as InputStream.readAllBytes() and InputStream.transferTo(). Technically, none of our Java 8 incompatibilities impact the server, except that we are building to --release=11, which will produce bytecode that Java 8 cannot read/run. We could in theory spend some time breaking up the build while still in Ant to compile gwt-servlet separate from gwt-user, but that's going to require some time to achieve. I also have ambitions for GWT 2.14 or so to be reworked into much smaller modules as part of mavenization (or gradle-ization, with an appropriate sponsor for the required build work), which would make that easier, but it isn't a goal of the work. A simpler version could just be to isolate a few classes/packages to run the gwt.javac targets on as either 8 or 11, but care will need to be taken so that this won't conflict/collide with the javax/jakarta split... Another option could be reverting/rewriting some recent work (deprecating/removing the grab-bag Util/Utility classes), and will also require avoiding upcoming Java FlightRecorder changes (to replace SpeedTracer, which doesn't exist as a runnable Chrome plugin any more, as far as I can tell). Finally, we could (as has been discussed in the past) consider backporting important changes to a Java 8 compatible branch. Naturally it wouldn't make sense to support any JDT updates, newer JRE emulation or large refactors for future modularization, but I'm sure some commits might make sense to backport (Java 8 String.split semantics perhaps?). But as it stands, we are going to lose Java 8 support on the server in GWT 2.13 without some volunteered/sponsored efforts. On Monday, October 27, 2025 at 1:22:52 PM UTC-5 Jens wrote: > GWT has a hard dependency on JDT so I see it pragmatic and I would let GWT > require to what JDT requires in order to support the latest Java language > features. And for that version the latest Jetty server can be chosen. > > Given that GWT is in maintenance mode GWTs server libraries can stay at 8 > as long as feasable because there is no real benefit updating the > requirement. But for running GWT compiler / DevMode I really don't mind > which Java version is required and I don't see any reason why GWT needs to > be extra conservative here. It is just the VM to run a tool and has nothing > to do with the final deployment. > > -- J. > > Colin Alworth schrieb am Sonntag, 26. Oktober 2025 um 20:28:58 UTC+1: > >> Its been about three years since the last thread on deprecations, and the >> Java 8 deprecation ended up going by with barely a whisper. >> >> On the other hand, I'm hearing more interest in Java 21+ features than we >> did for Java 17 at the time - but updating JDT so that we can provide those >> will require dropping support to run on Java 11. >> >> We seem to be close to a GWT 2.13 release, so GWT 2.14 would be the >> earliest this would take place. The expectation in turn would be that our >> JDT version would then be updated, and possibly Jetty as well. Thoughts? >> > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/c94f2949-9ba1-42bc-8f3c-c75c17ddfd3fn%40googlegroups.com.
