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 <https://adoptium.net/support/>, 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? On Sunday, August 7, 2022 at 1:16:56 PM UTC-5 stuckagain wrote: > 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 <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 > <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> > . > > -- 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-contributors+unsubscr...@googlegroups.com. 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.
