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.
On 4 Aug 2022, 06:05 +0300, Colin Alworth , 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.
>
>
> 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
