DIscussing dropping support for Java 11

[Colin Alworth]

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?

[Frank Hossfeld]

I see no reason to support Java 11 now. Many of my clients are already on Java 17 or planing to move to Java 17 in the near future.  

I think, the benefit of dropping support for Java 11 is much greater than supporting it. So, from my point of view: let's drop it. 

[Axel Uhl]

https://devclass.com/2025/01/30/state-of-java-report-shows-strong-migration-from-java-8-rise-of-apache-spark/
from January 2025 lists 46% of Java projectcs being on Java 8 and older.
I'm not aware of stats about GWT usage; my assumption is that not too
many new projects are being started with GWT these days. There may well
be a correlation of GWT users with users of older JDKs.

For us, with https://github.com/SAP/sailing-analytics we have been using
GWT since 2011. Our production runtime is still on SAPJVM8 for a number
of reasons, although we also ensure runtime compatibility up to Java 24.

https://github.com/gwtproject/gwt/issues/7987, which is essential for
our operations, wasn't pulled by the GWT team, so we're on a fork
(https://github.com/SAP/gwt-forward-serialization-rpc) anyhow and can
probably never make it back to a more modern version of GWT. As such, we
may afford the luxury of just not caring, although we'd love to see
compiler bugs such as in determining serializability of cyclic type
graphs with custom field serializers and generics fixed at some point...

Just keep the 46% in mind, most of which you've already cut off when
requiring Java 11...

Best,
-- Axel

> --
> 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 google-web-toolkit-co...@googlegroups.com
> <mailto:google-web-toolkit-co...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/google-
> web-toolkit-contributors/72985f8a-9704-441a-
> b7aa-7d87c6efb044n%40googlegroups.com <https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/72985f8a-9704-441a-
> b7aa-7d87c6efb044n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Thomas Broyer]

On Monday, October 27, 2025 at 10:37:49 AM UTC+1 hthdjeu...@googlemail.com wrote:

https://devclass.com/2025/01/30/state-of-java-report-shows-strong-migration-from-java-8-rise-of-apache-spark/
from January 2025 lists 46% of Java projectcs being on Java 8 and older.
I'm not aware of stats about GWT usage; my assumption is that not too
many new projects are being started with GWT these days. There may well
be a correlation of GWT users with users of older JDKs.

For us, with https://github.com/SAP/sailing-analytics we have been using
GWT since 2011. Our production runtime is still on SAPJVM8 for a number
of reasons, although we also ensure runtime compatibility up to Java 24.

[…]

Just keep the 46% in mind, most of which you've already cut off when
requiring Java 11...

Server runtime is different from GWT tooling at dev/build time.

GWT server libs (gwt-servlet, requestfactory-server) still support running on Java 8: https://www.gwtproject.org/release-notes.html#Release_Notes_2_12_0

What we're talking about (still, I believe) is requiring JDK 17+ for running the GWT compiler and code server.

[Vassilis Virvilis]

For me current GWT development governance achieves a delicate balance between stability and new features.

GWT has been compatible with 8 long enough for me to jump to 11, then 17 and now to 21.

So for me personally it's ok to drop support for 11.

I can relate with other people that haven't had the opportunity to do the jump though.

Finally I believe that if your dev environment is 21 it would be difficult to produce compatible code with 8.

So most people that will do the jump, they will probably bite the bullet and will do it both client side and server side.

    Vassilis

--

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 google-web-toolkit-co...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/3d5fee61-a423-4a43-b55b-0e8b7055c669n%40googlegroups.com.

--

Vassilis Virvilis

[Thomas Broyer]

On Monday, October 27, 2025 at 12:09:11 PM UTC+1 vas...@gmail.com wrote:

Finally I believe that if your dev environment is 21 it would be difficult to produce compatible code with 8.

So most people that will do the jump, they will probably bite the bullet and will do it both client side and server side.

I have several projects that require a JDK 21 toolchain but produce Java 8 bytecode, --release 8 makes it a breeze (with no fear of using incompatible APIs either), so not really a compelling argument.

[Matt Davis]

We have been on Java 21 for a long time now.  I feel like the transition from 11 to 17 is easier than the transition from 8 to 11 so I do not see a compelling reason to support 11.

--

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 google-web-toolkit-co...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/9c9a04a7-706b-4ff1-8dd5-6783053f15adn%40googlegroups.com.

[Jens]

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:

[Colin Alworth]

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.

[Colin Alworth]

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