JFR notwithstanding, it was simpler than I thought to get all of gwt-user to be restricted to Java 8, just for the benefit of gwt-servlet. This may be a temporary measure, but should work at least through the 2.13 release.
https://github.com/gwtproject/gwt/pull/10195 On Thursday, November 20, 2025 at 5:01:43 PM UTC-6 Colin Alworth wrote: > 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/2a9b5b04-e3f9-47ea-b434-bfa8843b2f75n%40googlegroups.com.
