[gwt-contrib] Re: GWT 2 Roadmap as it applies to future deprecations
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? On Monday, January 2, 2023 at 12:49:36 PM UTC-6 eliasbala...@gmail.com wrote: > 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. > > On Monday, 2 January 2023 at 13:10:59 UTC hthdjeu...@googlemail.com wrote: > >> 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
[gwt-contrib] Re: GWT 2 Roadmap as it applies to future deprecations
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. On Monday, 2 January 2023 at 13:10:59 UTC hthdjeu...@googlemail.com wrote: > 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. > On Thursday, August 4, 2022 at 5:05:45 AM UTC+2 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
[gwt-contrib] Re: GWT 2 Roadmap as it applies to future deprecations
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. On Thursday, August 4, 2022 at 5:05:45 AM UTC+2 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
[gwt-contrib] Re: GWT 2 Roadmap as it applies to future deprecations
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. -- 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/23ea079e-8be3-4245-a6c4-3f4c4c5553e0n%40googlegroups.com.
