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] Re: GWT 2.10 release?

[Matt Davis]

awesome +1

On Fri, Oct 1, 2021 at 2:31 PM mcmi...@gmail.com  wrote:

> Sound greats +1
>
>
> nilo...@gmail.com schrieb am Donnerstag, 30. September 2021 um 21:22:13
> UTC+2:
>
>> We've got a few changes that have been brewing or waiting to be made
>> available, and it sounds like it is about time to collectively push to make
>> these things happen. Given the nature of some of these, I am suggesting
>> that they not be folded into a bugfix release, but instead that the next
>> release be 2.10.0.
>>
>>
>> Changing Maven Central groupId
>> One of the big ones is work to migrate off of the "com.google.gwt"
>> groupId (note that we are not adjusting packages) and into our own
>> namespace in maven, "org.gwtproject.gwt". Google's efforts to open sourcing
>> and encourage GWT has been very accommodating for the community, and this
>> change is long past due, so that releases of GWT do not need someone with
>> access to the com.google groupId in Maven Central to perform the release
>> process for us. If successful, this will be the final release which uses
>> the old groupId.
>>
>> To that end, Thomas Broyer has done a lot of work to make sure this path
>> will be as smooth as possible. That work can be seen discussed in the
>> mailing list
>> 
>> and in a github repo he wrote
>>  to demonstrate
>> approaches and their relative merits. No final summary was officially
>> posted, but from discussions in gitter chat
>> , the
>> cleanest proposed option is to follow Experiment #3 for today, and
>> optionally later to roll out the last two options to more easily facilitate
>> updates from older releases.
>>
>> This means that the next release will be performed first on
>> org.gwtproject, and then later we will request that someone at Google
>> perform the final com.google.gwt release, consisting only of pom files that
>> indicate relocation to the new groupId. Applications and dependencies will
>> need to switch to this new groupId over time, but in theory at least, using
>> the researched relocation mechanism should make that fairly painless.
>>
>> Finally, I suggest that any release candidate that goes out only exist on
>> org.gwtproject, to avoid needing to iterate with com.google releases, in
>> case we end up needing more than one RC in the release process.
>>
>> --
>>
>> Chrome debugging bugs
>> There are a few changes in Chrome made over the last year or so that
>> impact GWT development and debugging in various ways.
>> https://gwt-review.googlesource.com/c/gwt/+/23500 fixes SDM (and cross
>> origin apps) stack traces being lost, and unhandledrejection events are
>> entirely lost in some cases.
>> https://gwt-review.googlesource.com/c/gwt/+/23580 tracks a newer change
>> in Chrome dev tools, where the unofficial Function.displayName property no
>> longer works when debugging obfuscated code with GWT's
>> -XmethodNameDisplayMode flag, and transitions to the standard Function.name
>> property instead.
>>
>>
>> --
>>
>> IE8/IE9/IE10 removal
>> Another thread on this mailing list
>> 
>> tracks the ongoing discussion of removing three end-of-life'd browsers from
>> GWT. It has been suggested that IE11 support remain for at least a little
>> while longer. According to
>> https://docs.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge,
>> IE11 as a desktop application will no longer be supported after June 2022,
>> though that may change, and even if it does not, it may make sense to
>> continue support for some time after that.
>>
>> --
>>
>> Dropping Java 7 support, and upgrading Jetty 9 and HtmlUnit
>> Building GWT itself with something newer than Java 8 is going to require
>> additional work (see https://github.com/gwtproject/gwt/issues/9683), but
>> the time has come to no longer support Java 7, and require 8 as the minimum
>> version for building and using GWT. I have a work in progress patch
>> 
>> which upgrades both Jetty 9 and HtmlUnit to their latest respective
>> versions in order to deal with several issues affecting each. I am holding
>> out for one last fix in HtmlUnit before disabling the two tests it affects
>> (note that this is still a net win, about a dozen tests are now passing
>> that weren't previously).
>>
>> --
>>
>> Other changes already in HEAD-SNAPSHOT can be seen at
>> https://github.com/gwtproject/gwt/compare/2.9.0...master.
>>
>> --
> 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
> 

Re: [gwt-contrib] Re: Goodbye IE 8–9 

[Matt Davis]

+1 drop all i.e.

On Thu, Sep 30, 2021, 4:13 PM Juan Pablo Gardella <
gardellajuanpa...@gmail.com> wrote:

> +1 drop IE 11 increases the effort to include new stuff. IE +11 can still
> use GWT 2.9.0
>
> On Thu, 30 Sept 2021 at 16:55, Vegegoku  wrote:
>
>> I vote to even drop support for IE11.
>>
>> On Thursday, September 30, 2021 at 7:49:56 PM UTC+3 nilo...@gmail.com
>> wrote:
>>
>>> I've just filed https://github.com/gwtproject/gwt/issues/9739, where a
>>> workaround exists in java.util.Date that nearly doubles the time it takes
>>> to parse date strings and build date objects. This workaround exists for
>>> IE8 and IE9, as all more recent browsers implement the same behavior as we
>>> already would expect. Dropping support for those two browsers would
>>> simplify the code required here
>>>
>>> From the age of this thread and the discussion so far, it sounds like
>>> there is interest in keeping IE11 still, but no one has spoke up about IE10
>>> or below.
>>>
>>> Additionally, java.util.Random emulation was changed to require
>>> Date.now(), which isn't available in IE8, so neither GWT 2.8.2 nor GWT
>>> 2.9.0 are apparently compatible with IE8 anyway, at least in this small
>>> way. This should give us some confidence (along with the lack of opposition
>>> in this thread) that at least IE8 is definitely safe to drop.
>>>
>>> So, is there any objection at this time to dropping what remains of IE8,
>>> IE9, and IE10 support from GWT? Then, we can reevaluate IE11 at some later
>>> date, for GWT itself? Various migrated GWT modules have focused their
>>> efforts on well-supported browsers, and are likely to only support IE11 by
>>> accident anyway.
>>>
>>> On Friday, March 12, 2021 at 1:20:02 AM UTC-6 stuckagain wrote:
>>>
 We still need IE11 support in the banking sector. We still have a
 majority of customers that use IE11 due to technical reasons (plugins
 needed for accessing secure token don’t install properly in Chrome without
 internet access amongst others).

 What do you mean with “next version of GWT” if that is 3.x then I don’t
 care at this point. We have been waiting for that release for a few years
 now. But 2.x releases should not drop IE11 support it is supposed to be a
 long-term supported version.
 On 12 Mar 2021, 07:54 +0100, bernhar...@schubec.com <
 bernhar...@schubec.com>, wrote:

 Hi all!

 I think IE11 support should be dropped soon if it blocks (or makes it
 difficult) to implement new features in the next version of GWT.
 I understand, that there are enterprises who still use IE11 internally,
 but developers who service such enterprises should use the current version
 of GWT, which is not going away. Nobody is forced to upgrade to the next
 version of GWT.

 Thanks,
 Berni

 tony.be...@gmail.com schrieb am Donnerstag, 11. März 2021 um 22:26:21
 UTC+1:

> IE 11 is still widely used inside corporations, because it is the only
> browser that supports Java applets, and applications such as Oracle
> e-Business Suite still use applets extensively (for Oracle forms). While
> that segment does not move very fast, it does not mean other unrelated
> groups within the same corporation are not updating GWT regularly. It is
> hard to generalize In a multinational company  with tens of thousands of
> employees.
>
> Regards
>
> Tony
>
> On Thu, Mar 11, 2021 at 9:49 AM Jens  wrote:
>
>> Dropping IE 8-10 shouldn't really hurt. Companies that require it are
>> probably not upgrading GWT in a fast pace anyways.
>>
>> However I wouldn't drop IE 11 anytime soon. IE 11 itself is tied to
>> the lifecycle of Microsoft's operating systems, which means for Windows 
>> 10
>> it is supported until 2025 (for now). So just because MS and Google drop
>> support for IE 11 in some/all of their products, the browser itself is
>> still generally supported by MS. So we should think twice before removing
>> IE 11 from a library such as GWT, even if it means to decline/revert
>> certain commits if they break IE 11. From own experience I have usually
>> seen something around 8% of IE 11 usage in GWT based apps.
>>
>> However I am pretty sure more and more companies will announce
>> dropping IE 11 this year or next year. With MS and Google starting, this
>> could easily have a domino effect. However GWT also also strongly used
>> internally inside companies so it might not have that much of an effect 
>> in
>> that area.
>>
>> If we ditch IE 8-10 and only leaving gecko1_8 and safari, can't we
>> kill them both as well and put them together? Are there so many 
>> differences
>> in code between both? From my work migrating GWT code to
>> elemental2/JsInterop I had the feeling that only some minor stuff is
>> different between both. So there shouldn't be that 

Re: [gwt-contrib] Goodbye IE 8–9 

[Matt Davis]

I can't see an argument for keeping any IE version supported with both
microsoft and google dropping support.  Hopefully dropping support would
also allow some optimizations or simplifications. Internally, we were
planning on supporting IE11 until microsoft dropped support and forced the
issue.


On Wed, Mar 10, 2021 at 4:34 AM 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> I highly recommend dropping IE11 as well in the next release. It will be
> no longer supported by Microsoft and GMail and Google Workspace will be
> dropping its support in March 15:
>
> https://workspaceupdates.googleblog.com/2020/12/ending-support-for-ie11-for-all-google-workspace.html
>
> That means internally we will stop testing and developing for it and
> things may start breaking over time.
>
> On Wed, Mar 10, 2021 at 1:21 AM Thomas Broyer  wrote:
>
>> Fwiw, a change in GWT emulation of longBitsToDouble and doubleBitsToLong (
>> https://gwt-review.googlesource.com/c/gwt/+/23140) has landed that uses
>> Typed Arrays. This means they won't work in IE8 and IE9 anymore:
>> https://caniuse.com/typedarrays
>>
>> Maybe it's time to remove support for those old versions? (it's long
>> overdue if you ask me)
>> I'd actually go as far as only keeping IE11 for the time being (which
>> uses the gecko1_8 permutation).
>> A first step might be to disable them by default, like we did for the ie6
>> and opera permutations in 2.6, removed in 2.7.
>>
>> Fwiw, for a while now, gwt-maven-archetypes has had > name="user.agent" value="ie10,gecko1_8,safari" /> (i.e. it already disabled
>> ie8 and ie9), and I'll change it to gecko1_8,safari soon.
>>
>> --
>> 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/5adb9f2d-d8df-45c9-a084-d361df389979n%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/CAN%3DyUA0FjL2ACrrG57qmnK4L6pHXLmzx4UwSrYkvSnYaifyhrQ%40mail.gmail.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_%3D%3Dv91yVoe5A%2B%2BTV8NoL4CZXzgHS5AcxFGZqjRxmn3w%40mail.gmail.com.

Re: [gwt-contrib] Required JDK version to build GWT?

[Matt Davis]

I agree with this statement: "it seems like the clearest win is to move all
the way to Java11, though continue to target java 8 releases, and test on
all JREs up until current."

On Mon, Jun 29, 2020 at 10:21 PM 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> wrt running tests:
> See https://gwt-review.googlesource.com/c/gwt/+/13861 for the pattern
> used in JRE earlier; and the CI was updated to run in both 7 and 8 at the
> same time.
>
> PS: Compiler tests ("jjs.test.Java8Test") was different because we really
> needed to run the compiler tests with new syntax inside Google which didn't
> have the Java8 VM at the time. It wasn't a deal breaker to be not able run
> Java8 JRE tests at the time so they are not super sourced.
>
> I recommend the same approach.
>
>
> On Mon, Jun 29, 2020 at 6:45 PM Colin Alworth  wrote:
>
>> As of somewhere in the time leading up to the GWT 2.9.0 release, it is no
>> longer possible to build GWT with Java7, and similarly the decision was
>> made to no longer officially support running on Java7
>> (jsinterop-annotations use of "TYPE_USE", newer jetty version too I
>> believe).
>>
>> There is still some defunct wiring in the build to handle Java 7 vs Java
>> 8 though, mostly with regards to running tests - since we first javac our
>> java classes, and then run gwtc on them, we need to make sure that the java
>> version being use can correctly compile those tests.
>>
>> The issue https://github.com/gwtproject/gwt/issues/9683 is tracking some
>> of the existing work on this: the main remaining piece is to decide how to
>> handle javadoc. GWT has its own custom doclet to handle a few custom tags,
>> "example", "gwt.include", and "tip". None of this compiles after Java 8,
>> since Java 9 came with a new, incompatible API to build custom tags, so
>> either we drop Java 8 support for building the toolkit, require _only_ Java
>> 8 to build, support two parallel copies of the custom doc wiring, or drop
>> the doc wiring entirely and remove these custom tags throughout the
>> codebase.
>>
>> Since the release of GWT 2.9 and my own work on the above ticket, I've
>> been picking back up some Java 9/10/11 JRE emulation work that I had
>> previously paused, and I'm running into the issue described at the top - if
>> you write a test that calls Map.of() and run it on Java8 as a GWTTestCase,
>> you'll get a compile error.
>>
>> Two basic ways I can easily see to fix this: we can make two copies of
>> each test, one as an empty "real" java type and one as supersource, or we
>> can guard those tests behind java version args in the build glue like we
>> did for Java7 vs Java8. The first option is clunky, and while I see this
>> was done for `com.google.gwt.dev.jjs.test.Java8Test`, it clearly wasn't
>> done for JRE emulation tests, and I assume there was a reason for that. The
>> second option requires changing our CI to build+test on some new JRE...
>>
>> ...and given the constraints of the Java LTS system, and the java 8/9
>> divide for custom doclet stuff, it seems like the clearest win is to move
>> all the way to Java11, though continue to target java 8 releases, and test
>> on all JREs up until current.
>>
>> So that's my pitch. For completeness, some other options that seem
>> workable, keeping in mind that at present there are about 3 important JRE
>> versions to support well: Java 8, Java 11, and the current stable release.
>>  * Require Java8 for javadoc, supersource tests
>>  * Allow any JRE 8+, use ant filters for tests for each version, maintain
>> two javadoc builds
>>  * Allow any JRE 8+, use ant filters, only actually produce javadoc on
>> java9+ builds
>>
>> Other technical ways to deal with this, or have a missed an easier
>> solution to one of these problems?
>>
>> --
>> 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/0aa0701b-4287-4e4c-bbef-23952898c64an%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/CAN%3DyUA1L4gAaaEkqgWnqL%3DiKDX_aUjX1L0WThdG4yuxUyHdQMQ%40mail.gmail.com
> 

Re: [gwt-contrib] Resolving cycle dependency between gwt-safehtml & gwt-safecss

[Matt Davis]

+1 to merge.

On Thu, Jun 25, 2020, 4:26 PM Juan Pablo Gardella <
gardellajuanpa...@gmail.com> wrote:

> +1 to merge them. It seems the simplest solution.
>
> On Thu, 25 Jun 2020 at 17:23, Colin Alworth  wrote:
>
>> One potential option could be moving the tests into gwt-safecss, and only
>> release them together - the release process through sonatype will permit
>> you to push more than one set of artifacts, test them in the staging repo,
>> and then release to central together. That would imply using either local
>> artifacts to build gwt-safecss (instead of pulling from central), or
>> temporarily adding the staging repo to the pom.
>>
>> It does seem simpler to just merge to gwt-safehtml - especially since I
>> doubt that gwt-safecss is often used by itself.
>>
>> On Thursday, June 25, 2020 at 3:19:05 PM UTC-5 juan_pablo_gardella wrote:
>>
>>> Not too much options I think, see
>>> https://stackoverflow.com/questions/55429921/how-to-fix-cyclic-dependency-between-java-modules
>>>
>>> Maybe a new common shared module (maven artifact in this case) or merge
>>> safehtml and safecss into a new one and let them deprecated.
>>>
>>> Juan
>>>
>>> On Thu, 25 Jun 2020 at 17:14, 'Frank Hossfeld' via GWT Contributors <
>>> google-web-tool...@googlegroups.com> wrote:
>>>
 To prepare GWT for j2cl we need to move the modules out of GWT, replace
 generators with ATP, etc. This is in progress and the first modules
 (SNAPSHOT) are released.

 Migrating gwt-safehtml and gwt-safecss runs into a problem, cause
 gwt-safehtml depends on gwt-safecss and gwt-safecss depends on
 gwt-safehtml. This is a serious issue, cause one can not be build and
 tested without the other.

 To solve this issue, we are looking for solutions.

 One solution might be to move the tests out of gwt-safehtml. But then
 gwt-safehtml needs to be build and deployed before the tests run and might
 be deployed with failing tests. That looks like a bad solution.  At the
 moment the idea is to move the sources and tests from gwt-safecss into
 gwt-safehtml and delete gwt-safecss. This will remove the cycle dependency
 between these two modules, but doing so, the module will be the first
 module that contains two old modules in one new.

 Any other ideas how to solve this issue?

 --
 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/a8d6c785-c8d9-4eba-8cc2-0b42ecac1124o%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/8b4addde-bf52-4a88-b38f-fd2c0493f9f9n%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/CA%2BkiFscwn64KFDxxoqNx5hKRWCVQZ08HkS9GkbZvw6%3D%3D_5YcWA%40mail.gmail.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/CAKAo3tSKeM_bywaLaQPqujdYwSe-DfGy-47JPTJnB1q%2BQHcxrA%40mail.gmail.com.

[gwt-contrib] Re: HashCode H$ property should be not enumerable

[Matt Davis]

I would love to see just ie11 supported. 

-- 
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/a829513d-bc84-456f-9f38-739747e65608o%40googlegroups.com.

Re: [gwt-contrib] GWT Java7 support

[Matt Davis]

I feel like many more people would enjoy a decent version of embedded
jetty. Java 7 hasn't had public support in awhile and Oracle premium
support ended this earlier this.

On Tue, Oct 22, 2019, 1:24 AM Jens  wrote:

> It’s kept so long because of java 7 servers and the fact that gwt-servlet
> doesn’t have its own ant compile target.
>
> But I guess it should be fine to drop java 7, it is also holding back
> upgrading embedded jetty to a decent version.
>
> --
> 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/b5eb4fbe-0471-479b-9734-56d33d9d129e%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/CAKAo3tSupuqgijH9sYu%2BN6fo-%2BBpPLuU4kzdpLSJHWUQ-QWC5A%40mail.gmail.com.