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
<https://spring.io/blog/2022/03/28/an-update-on-java-17-adoption>.
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?
--
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
<https://groups.google.com/d/msgid/google-web-toolkit-contributors/234ffccc-802d-45f3-ba20-17f3d8773fc5n%40googlegroups.com?utm_medium=email&utm_source=footer>.
