Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

[Thomas Broyer]

On Thu, Aug 4, 2022 at 5:05 AM 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.
>
> 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 

Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

[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

On 8/12/22 10:13, Colin Alworth wrote:
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?

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 , 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 

Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

[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? 
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 , 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 

Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

[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.
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 

Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

['Frank Hossfeld' via GWT Contributors]

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. 
 

stockiNail schrieb am Sonntag, 7. August 2022 um 18:10:35 UTC+2:

> 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.
>
> Il giorno sabato 6 agosto 2022 alle 22:38:52 UTC+2 m.conr...@gmail.com ha 
> scritto:
>
>> 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  
>> 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
>>> .
>>>
>>

-- 
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/83423468-8742-4dfe-b296-f8c5c7a713a8n%40googlegroups.com.

Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

[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.

Il giorno sabato 6 agosto 2022 alle 22:38:52 UTC+2 m.conr...@gmail.com ha 
scritto:

> 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  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
>> .
>>
>

-- 
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/f8a6e84c-129b-4a70-b2cc-d43e51494fdfn%40googlegroups.com.

Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

[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 
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-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/7868638.WIiY39HZoD%40t470
> .
>

-- 
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/CAFHWztxtQp%2Bq3CsfOfyTTuce5ZJ2xYCOnnuAYkOYpyE3nAVS1Q%40mail.gmail.com.

Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

[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).

On Sat, Aug 6, 2022 at 11:14 AM eliasbala...@gmail.com <
eliasbala...@gmail.com> wrote:

> 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.
>
> On Saturday, 6 August 2022 at 16:06:28 UTC+1 ManfredTremmel 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-contributors+unsubscr...@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
> 
> .
>

-- 
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/CAKAo3tR_cvCULiBgWA7O0eoXm8Rs0h%2B7V1FjyxXvW6zfMx-yPw%40mail.gmail.com.

Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

[eliasbala...@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.

On Saturday, 6 August 2022 at 16:06:28 UTC+1 ManfredTremmel 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-contributors+unsubscr...@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.

Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

[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.


-- 
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/7868638.WIiY39HZoD%40t470.

[gwt-contrib] 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