GWT 2 Roadmap as it applies to future deprecations

[Colin Alworth]

If there’s one thing that GWT has tried to be consistent about, it is retaining support for technologies past their “best by” dates. This is a sore point from time to time, as it makes the tooling feel dated even right after a release, but it has some specific advantages with regards to enabling projects that are otherwise in maintenance mode to still be able to upgrade to a newer version. Similarly, GWT has traditionally only supported the current release, with no fixes backported, due to the extra work that would need to be done in testing, backporting, etc.


To get stuck on a tangent before even reaching the point of this post, this is part of the reason that each of the GWT modules which previously lived in gwt-user.jar is getting its own git repo, and being released as its own pace, separate from the GWT compiler and its neighbors (and also separate from J2CL, with tests to ensure it can work with both toolkits). Migrating to a specific version of one of those modules might require some code changes be made to a project, but is intended to uncouple changes to that project from changes made to either J2CL or GWT2 toolchains.

GWT 2.10 has been released, with a few important changes that border on breaking - the groupId has changed from com.google.gwt to org.gwtproject, Jetty was updated after languishing for years, and IE 8, 9, and 10 support has been dropped. The Jetty change has caused a few minute hiccups, one of which will probably result in a GWT 2.10.1 release, but otherwise things seem to have gone well.

Looking forward, we have some other decisions to make around deprecating or dropping support for certain features or compatibility. The chief issue is dropping support for Java 8. Jetty 9 is EOL (though still receiving occasional security updates for now), and Jetty 10 requires Java 11 at a minimum. Recent versions of the Eclipse JDT will also require Java 11, so we can’t add support for Java 17 language features without dropping support for running on Java 8. While it is possible that we might be able to continue to compile gwt-servlet and other production server-side code for Java 8, that is going to need dedicated testing to ensure it behaves as we expect, so I wouldn’t want to have it be one of our first choices.

We would be in good company with dropping Java 8 in our next release - the Spring Framework has gone so far as to drop Java 11 support as well, requiring Java 17 as the minimum supported Java version as of version 6.

Other deprecations/updates/removals to consider - I haven’t spent a great deal of time investigating any of these, but wanted to at least open the door to some of these.

• Legacy Dev Mode - the use cases are diminishing but not totally gone yet. IE11 technically supports it, and HtmlUnit can use it as well. Some testing tools like gwt-mockito and Emma require it as well. With that said, if removed, there is considerable old code that can go with it, not just in the compiler and dev mode, but simplification that can happen in emulation as well.
• Selenium - Selenium support is ancient, and I’m not aware of a way to make it work with recent browsers. Moving to modern WebDriver would make sense, though this is a bit of a moving target in my experience, but downstream projects should be able to update without affecting GWT. It might even make sense to leave this as an optional dependency, and rely on the downstream project adding its own implementation.
• javax.servlet -> jakarta.servlet - This could potentially be done in a way to support both APIs in a single release, though that may also require supporting two sets of dev mode implementations, for users that run their own servlets in the dev mode server.

Inevitably, removing these before they are formally end-of-life’d is bound to inconvenience at least a few downstream developers, so this isn’t to be taken lightly, nor done without some plan to continue to support critical fixes. Some quick options, based on how much pushback we get on each:

• Keep all compatibility until the dependency in question is formally end-of-life’d. We’ll be waiting until something like 2026 to pick up the Java 17 support through JDT, though other options might be possible along the way.
• Be very aggressive in dropping support, such as Spring’s model, where the next release will only support Java 17+. This will undoubtedly cut off support for many projects far before they are ready to update.
• Let the main branch work towards updating some of these dependencies for a 2.11 release, and backport any fixes that don’t directly relate to upgrades to the release/2.10 branch. This would represent a shift in existing policy around releases, and might require more support from community members for testing and such. There is also the risk that 2.10 could miss out on some fixes. As the “current version” of Java is going to keep on marching forward, likely 2.12 and so on would continue to be released, and 2.10 would remain the “LTS” version.
• Same as above, but let 2.11 become the LTS release (so as to give the project time to adapt to being moved to GitHub, and to get a 2.10.1 out to fix known regressions), and let 2.12+ feel comfortable dropping support for Java 8, etc.
• Same as above, but a more complex plan where more than one version is maintained long-term, to allow (for example) 2.11 to drop Java 8, 2.12 to drop javax.servlet, 2.13 to drop Java 11 and so on. This could easily explode out of control with many backported fixes to manage and test.

I don’t want to dwell too much yet on exactly what should be dropped and when, at least until some initial conversation is had on generally handling deprecations and potentially picking a potential strategy for keeping a “LTS”-style release. Then, discuss community support needs for the various dependencies in a broader audience, and make decisions from there.

Thoughts on how to generally balance deprecations against updates?

[Jens]

I think first we should put a good Java version policy into place. Personally I would split this policy into two policies. One for client code (Compiler) and one for shared/server code.

For client code GWT has two main dependencies: Eclipse JDT and Jetty. So I would define the minimum required Java version of GWT Compiler / DevMode as the maximum of the requirements of latest Jetty and latest Eclipse JDT. That way GWT can always aim to support latest Java language features and can regularly upgrade Jetty for CodeServer / DevMode once the used Jetty version is EOL or something else requires upgrading Jetty. I think this should be fine for everyone because JDK on developer machines and within CI docker containers can be relatively new in case it needs to be relatively new. 

My gut feeling says with this policy we would usually end up with the previous LTS version of Java as a minimum requirement. Currently 11. 

For server side code we never know how it will be deployed. Some people aim to use newest Java on server, some don't. Jakarta EE 9 is the first release using the new jakarta namespace. As it requires Java 8 we could technically stay on 8 while supporting both namespaces for a long time. Jakarta EE 10 will require Java 11. 

IMHO it is important to support latest java language features in client/shared code. If GWT client/shared code lags behind GWT feels even more dated just because of missing language feature support. Thus our Java version policy should help us to never be blocked by server side Java requirements. 

-- J.

[Manfred Tremmel]

In my company Java 8 was dropped long ago, at the moment the migration from
Java 11 to 17 is in progress. So from my side, let's cut off the old stuff.

[eliasb...@gmail.com]

My 2 cents.

I am afraid some teams, like ours, are still using Java8 looking for the next opportunity to move to Java11.

Perhaps, Java8 shouldn't be dropped yet.

[Matt Davis]

We have been using Java 17 for some time now. But I think a policy of supporting the two most recent LTS (11, 17) would be fair.  In September 23 that would become (17, 21). 

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4996f471-8ed8-43af-9a88-96323483cf0an%40googlegroups.com.

[Michael Conrad]

My company is also migrating everything to JDK 17. The less opportunity for bitrot in future versions, the better.

On Sat, Aug 6, 2022 at 11:06 AM Manfred Tremmel <Manfred...@iiv.de> wrote:

In my company Java 8 was dropped long ago, at the moment the migration from
Java 11 to 17 is in progress. So from my side, let's cut off the old stuff.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/7868638.WIiY39HZoD%40t470.

[stockiNail]

In my opinion, my 2 cents, the support of JAVA 8 and IE11 should be dropped because very close to be obsoleted.

Whoever is using these platforms could stay on current version of GWT where they are supported.

I still have some applications based on Java 8 but they will remain with GWT 2.8.2 and when I could migrate them, I'll go to Java 11 or more and GWT accordingly.

[Frank Hossfeld]

Same here. It's time to move forward. Java 8 and IE 11 should be dropped. In case someone will stay with Java 8 he can use GWT 2.10.0.

I'll expect new versions of GWT will - in many cases - bring new language features. So, someone staying with Java 8 is not interested in updating. 

[David Nouls]

In my case we have different codebases that overlap with reusable components. Not all projects are willing to invest in a newer jdk since they are basically in maintenance mode.

If GWT would drop Java 8 it would be a problem. On the other hand, maybe it will finally force people to move on faster. They tend to complain that we are using old technology (GWT) but at the same time they stick with Java 8.

--

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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/234ffccc-802d-45f3-ba20-17f3d8773fc5n%40googlegroups.com.

[Colin Alworth]

Thanks to everyone for their insights. By my count, 25% of the replies have at least some use for Java 8 yet, so as the example that all responders latched on to, it seems unlikely that the time has come to drop support for it, at least in production deployments (a useful distinction that Jens drew).

With that said, I'd like to more specifically focus on the release side - as conflicts arise, do we "split" releases and support both "old" and "new", or do we find a single consistent path of least resistance? A single path could require a bit more work to implement up front (such as build wiring to ensure Java8 support in server jars, but runtime support for 11+), while a split path would probably keep better coverage over use cases at the cost of additional release testing (backporting a fix requires a release for both leading and trailing versions).

Historically we have held off updating dependencies until there was no choice, to ensure that nearly every GWT project could update promptly - so that any performance improvements or security fixes could be quickly put to use. Looking at Java 8 specifically, we have several years before Java 8 will be EOLd. At a quick glance, I'm not seeing an obvious EOL for the implementations of javax.servlet packages (Jetty 10, specifically), so I'm not sure we can afford to do more than implement both sets of interfaces and hope for the best, unless we again split as "leading"/"trailing" builds... but to reiterate, there are other cases here where we could remove or improve code based on dependencies that someone might still have a need for.

Worst case, I'm wrong, and we should focus first and foremost on exactly what deprecations should be handled, but with 25% of respondents so far with need of a version of Java that Adoptium intends to support until at least 2026, I think there might be merits to considering how that support could look for GWT. The question I'm trying to pose is how will we manage that - lighter testing on the old builds, focusing on only old dependencies and encouraging adoption of the newer release?

Are developers on this list (deliberately sent to the contributors list, not the general user mailing list) who don't update right away to new APIs (new JDK, javax vs jakarta, etc) interested in supporting work to keep a "LTS" release active (i.e. mostly validating backported fixes and smoke testing releases)? If so, is 2.10 that LTS, or do we want a short round of 2.11 for any more changes before beginning to "break" things in 2.12?

And if not, will it be acceptable to stay on stale versions of GWT, and while some effort will be put into keeping backwards compatibility, it will not outweigh needs like supporting modern servlet packages, drop "dev mode" htmlunit, etc?

[Michael Conrad]

My 2¢ worth  is that it would be good to have a split path with both a branch (GWT 2.10.x) for only security updates and misc fixes as a bug fix only LTS and also a current Stable branch (GWT 3.x)  that implements new language features and tracks with most recent Java LTS. This is especially important to us here  at where I work as we are currently migration to JDK 17 for everything and would like to take advantage of some of the JDK17 language features in shared code between GWT and Servlets. This would also allow developers the ability to have a more aggressive approach to adding new features and removing old cruft like IE x stuff or the need for permutations. Of course if would be idea to keep GWT 3.x compatible with GWT 2.10.x - but if a breaking change is needed to move the GWT ecosystem forward and keep things relevant - then doing so with a branch that would allow such would be ideal. I think godot-engine does something similar with their 3.x and 4.x branches.

As an aside, I think it would be good to have the foundation setup a patreon account to accept donations for funding future development.

-Michael/NewsRx

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/d9dd74dc-0534-41ba-8edf-c2b855e4417an%40googlegroups.com.

[Thomas Broyer]

On Thu, Aug 4, 2022 at 5:05 AM Colin Alworth <nilo...@gmail.com> wrote:

If there’s one thing that GWT has tried to be consistent about, it is retaining support for technologies past their “best by” dates. This is a sore point from time to time, as it makes the tooling feel dated even right after a release, but it has some specific advantages with regards to enabling projects that are otherwise in maintenance mode to still be able to upgrade to a newer version. Similarly, GWT has traditionally only supported the current release, with no fixes backported, due to the extra work that would need to be done in testing, backporting, etc.


To get stuck on a tangent before even reaching the point of this post, this is part of the reason that each of the GWT modules which previously lived in gwt-user.jar is getting its own git repo, and being released as its own pace, separate from the GWT compiler and its neighbors (and also separate from J2CL, with tests to ensure it can work with both toolkits). Migrating to a specific version of one of those modules might require some code changes be made to a project, but is intended to uncouple changes to that project from changes made to either J2CL or GWT2 toolchains.

GWT 2.10 has been released, with a few important changes that border on breaking - the groupId has changed from com.google.gwt to org.gwtproject, Jetty was updated after languishing for years, and IE 8, 9, and 10 support has been dropped. The Jetty change has caused a few minute hiccups, one of which will probably result in a GWT 2.10.1 release, but otherwise things seem to have gone well.

Looking forward, we have some other decisions to make around deprecating or dropping support for certain features or compatibility. The chief issue is dropping support for Java 8. Jetty 9 is EOL (though still receiving occasional security updates for now), and Jetty 10 requires Java 11 at a minimum. Recent versions of the Eclipse JDT will also require Java 11, so we can’t add support for Java 17 language features without dropping support for running on Java 8. While it is possible that we might be able to continue to compile gwt-servlet and other production server-side code for Java 8, that is going to need dedicated testing to ensure it behaves as we expect, so I wouldn’t want to have it be one of our first choices.

We would be in good company with dropping Java 8 in our next release - the Spring Framework has gone so far as to drop Java 11 support as well, requiring Java 17 as the minimum supported Java version as of version 6.

Other deprecations/updates/removals to consider - I haven’t spent a great deal of time investigating any of these, but wanted to at least open the door to some of these.

• Legacy Dev Mode - the use cases are diminishing but not totally gone yet. IE11 technically supports it, and HtmlUnit can use it as well. Some testing tools like gwt-mockito and Emma require it as well. With that said, if removed, there is considerable old code that can go with it, not just in the compiler and dev mode, but simplification that can happen in emulation as well.
• Selenium - Selenium support is ancient, and I’m not aware of a way to make it work with recent browsers. Moving to modern WebDriver would make sense, though this is a bit of a moving target in my experience, but downstream projects should be able to update without affecting GWT. It might even make sense to leave this as an optional dependency, and rely on the downstream project adding its own implementation.
• javax.servlet -> jakarta.servlet - This could potentially be done in a way to support both APIs in a single release, though that may also require supporting two sets of dev mode implementations, for users that run their own servlets in the dev mode server.

A much more problematic move is javax.validation → jakarta.validation. This API is used not only in JSR 330 emulation, but also in the Editor framework and in RequestFactory.

I'd vote for keeping javax.validation there (things could change in org.gwtproject module, but keep it that way in gwt-user).

Similarly, for javax.servlet → jakarta.servlet, I'd keep javax.servlet for as long as possible (Jetty 10) in GWT proper, and possibly move to jakarta.servlet in org.gwtproject modules. This means using such jakarta.servlet modules wouldn't be possible in DevMode and would require a separate servlet container (which is a good thing anyway).

 

Inevitably, removing these before they are formally end-of-life’d is bound to inconvenience at least a few downstream developers, so this isn’t to be taken lightly, nor done without some plan to continue to support critical fixes. Some quick options, based on how much pushback we get on each:

• Keep all compatibility until the dependency in question is formally end-of-life’d. We’ll be waiting until something like 2026 to pick up the Java 17 support through JDT, though other options might be possible along the way.
• Be very aggressive in dropping support, such as Spring’s model, where the next release will only support Java 17+. This will undoubtedly cut off support for many projects far before they are ready to update.
• Let the main branch work towards updating some of these dependencies for a 2.11 release, and backport any fixes that don’t directly relate to upgrades to the release/2.10 branch. This would represent a shift in existing policy around releases, and might require more support from community members for testing and such. There is also the risk that 2.10 could miss out on some fixes. As the “current version” of Java is going to keep on marching forward, likely 2.12 and so on would continue to be released, and 2.10 would remain the “LTS” version.
• Same as above, but let 2.11 become the LTS release (so as to give the project time to adapt to being moved to GitHub, and to get a 2.10.1 out to fix known regressions), and let 2.12+ feel comfortable dropping support for Java 8, etc.
• Same as above, but a more complex plan where more than one version is maintained long-term, to allow (for example) 2.11 to drop Java 8, 2.12 to drop javax.servlet, 2.13 to drop Java 11 and so on. This could easily explode out of control with many backported fixes to manage and test.

I don’t want to dwell too much yet on exactly what should be dropped and when, at least until some initial conversation is had on generally handling deprecations and potentially picking a potential strategy for keeping a “LTS”-style release. Then, discuss community support needs for the various dependencies in a broader audience, and make decisions from there.

Thoughts on how to generally balance deprecations against updates?

Separating gwt-dev (the toolchain) from gwt-user (the APIs), I'd be rather "aggressive" with the toolchain (drop JDK 8 if we need to for updating a dependency and e.g. gaining Java 17 language support) but more "conservative" with the APIs (using '--release 8' to target JDK 8). Using toolchains with Maven or Gradle, it should be "relatively easy" to call the GWT toolchain using JDK 11 or 17 while building everything else (possibly even including 'javac') with JDK 8, and if not possible, then just don't update GWT. The '--release 8' would make sure the code can run in a Java 8 environment (if you trust the JDK on it, I do), and all that'd be needed would be to make sure the dependencies are all Java 8-compatible (this only applies to dependencies that are needed at runtime, i.e. dependencies of gwt-servlet and requestfactory-* artifacts).

Ideally we'd separate client vs server to target different Java versions, but the build currently doesn't really make it easy, so simply compiling gwt-user with '--release 8' should be enough, at least to begin with. Using retrolambda or similar might be a possibility (either when producing/packaging gwt-servlet, or asking users to do it on their side when consuming gwt-servlet for a Java 8 environment).

This should make it possible to:

• update projects already on JDK 11+ without API breaking change (no javax → jakarta change)
• continue to target JDK 8 runtime environments, at the price of having to use JDK 11+ (or possibly even 17+) at build time when invoking the GWT toolchain (compiler, codeserver, GWTTestCase)

--

Thomas Broyer
/tɔ.ma.bʁwa.je/

[Axel Uhl]

We have a project here that uses GWT for all its web UI and is still running Java 1.8. The SAP JVM 8 will be supported at least until 2030. According to https://newrelic.com/resources/report/2022-state-of-java-ecosystem in April 2022 still close to half of the projects (46%) were using Java 1.8. We have made some efforts to move to 11 and 17 and succeeded to the degree that we have the build pipelines running for those two new LTS versions using their respective JDKs to compile, have our Docker images ready and can run the solution with both these new Java LTS releases. But this took a few months, and I find it very likely that from the 46% of the projects not all have the resources to invest into the migration. If only half of them do, we're still at those ~25% that Colin already sampled from the responses on this thread who will continue to use 1.8 for some time to come.

Still, we're not yet decided on making the move. Even when using the sapmachine.io flavors of the new JDKs we will lose some beloved features we get from SAP JVM 8, among them a really neat profiler that integrates nicely with Eclipse, as well as reversible on-the-fly debugging. The only immediate incentive for a migration to 17 could be the performance improvements we measure (depending on the type of workload an average improvement by 10-20%), whereas language features or the new GCs (which frankly were a bit disappointing for our parallelizing workloads) are not in such high demand in our case.

Ironically, since we live off a fork of the GWT project to already incorporate two PRs we've made into our production, Java 1.8 is still required to run the GWT build...

The compatibility issues raised here are of course all very valid. Some things seem reasonably easy to deal with (see, e.g., https://github.com/gwtproject/gwt/pull/9791). Other cases, some of which discussed here, too, such as potentially giving up the classic DevMode in a future release, and removing support for old IE versions in the current 2.10 release, may break existing projects for sure. The same applies for potential changes that don't deal "only" with bumping versions of dependencies but that try to improve aspects of GWT at the expense of what I would call minor compatibility glitches (see the discussion here: https://github.com/gwtproject/gwt/pull/9779).

With some of these things I find it a problem that GWT doesn't seem to have a clearly defined "set of contracts" based on which "backward compatibility" could be defined. There are, e.g., things that for technical reasons have been made "protected" in non-final classes or public in other classes that probably shouldn't count as part of the "GWT contract." Yet, with enough projects out there in the wild there may be a few that exploit exactly those elements and hence would break in case of changes in those areas. Disallowing any change in any of these areas, however, may box GWT in this compatibility trap forever. And having to postponse such changes to releases that will break massively in other areas and hence may cause disruption and lack of adoption for a fair share of GWT-based projects doesn't seem ideal to me, either.

Maybe we should take away from these challenges that it would be a good thing going forward to be more explicit abut which parts of GWT are contract and which ones are not; and those latter ones we then should be able to change incompatibly without worrying about adopters.

[eliasb...@gmail.com]

My 2 cents:

We also have quite a few projects here based on GWT, still running DevMode on Java 1.8 I am afraid.

Like everyone else sharing the same fate, we are struggling to upgrade to Java 11 which seems to be the next sensible move.

Yet, the world is being indirectly and inevitably forced to embrace the transformation challenge, as relevant tools and integrations have already switched to Java 11 (e.g. Jenkins).

In our experience, when using DevMode, it is best to run simpler variants of the actual UI apps, or keep them as simple as possible so that they can still run on Jetty even with an altered classpath.

[Colin Alworth]

I'd welcome a separate discussion about a backward compatibility contract, but clearly we have to contrast the "technically Java 8 is supported" with "realistically, any project that uses standard up-to-date tools can't use Java 8 by the end of 2023". We support _end users_ to the extreme, as so many huge enterprise apps built with GWT end up in situations with ancient PCs running out-of-date browsers, but we may need to consider Java or jakarta versioning to be different, as those face the developers and deployments.

If we assume that support Java 8 is required, we have roughly two options:

 * Support it only on the server, but not dev mode. GWT can migrate to Java 11/17/etc but be sure that gwt-servlet.jar and the like are only built with with Java 8 bytecode. This add a small amount of complexity to the build, and limits use of new features, but unblocks the compiler and dev mode from supporting newer versions of Jetty, JDT, etc. Jetty 9 is EOL, and 10 and 11 require Java 11. In turn, this is going to cut us off from HtmlUnit updates before much longer. Any recent JDT also requires Java 11, so we're cut off from records, multi-line strings, pattern matching, etc. Closure-compiler has also dropped Java 8 support, as another example (from Google, which famously requires Java 7 support for so long).

 * Support two long term releases, whereas we only support "the latest release" today, and don't backport fixes. This imposes very little burden today, as most commits will go in both branches, but costs will go up as time goes on, especially if we expect to make it until _at least_ 2030 with a long running 2.11 branch or whatever. It wouldn't quite double our current review/testing/release overhead, but I suspect it will be close to that in five years.

Either way we're starving for code reviewers and testers today - reported bugs may get fixes, but those fixes are not being tested and critical reviews are not being done. So I put this to teams that will require Java 8 in 2023 and beyond: additional support of some kind or another is required to maintain your use case. Do you need to deploy to Java 8 environments, or do you need to do all development in Java 8 as well? Are you able to coordinate with us to help make your use case a reality?