Re: Seeking Advice on Legacy Application Migration Strategy

[Colin Alworth]

You might run into issues with such an old version of GXT when using a new 
GWT version - take a look at 
https://groups.google.com/g/google-web-toolkit/c/If897MPqvw0/m/bSWnmuz9BwAJ 
for a summary of how to update GXT 2.3.1a-gwt22. 

With GWT updated to 2.9.0 or beyond, you will be able to run on Java 11 
(see https://www.gwtproject.org/release-notes.html#Release_Notes_2_9_0). 




On Friday, April 26, 2024 at 7:59:27 AM UTC-5 wejden...@gmail.com wrote:

> Many thanks @frank Hossfeld, 
> I am so excited to start it .. it is clear 
> please feel free to share any references or links that can help me in that 
> adventure .
>
> thank you
> wm
>
> Le ven. 26 avr. 2024 à 11:50, 'Frank Hossfeld' via GWT Users <
> google-we...@googlegroups.com> a écrit :
>
>> GWT 2.8.2 is pretty old - nearly seven years - and i am not sure, if the 
>> GWT 2.8.2 will work with Java 11
>>
>> Migrating to the latest version of GWT will give you some benefits. IIRC 
>> GWT 2.8.2 generates at least 5 JS-files where GWT 2.11.0 only generates 2. 
>> This will speed up the build. Also, there is a security issue in older GWT 
>> versions (in case you are using RPC). 
>>
>> To do so, separate your code in client-, shared- and server-modules (as 
>> Craig already mentioned).  Take a look here: 
>> https://github.com/tbroyer/gwt-maven-archetypes or here 
>> https://github.com/NaluKit/gwt-maven-springboot-archetype. This should 
>> give you an idea, how your project look like after the separation. Once 
>> done, it should be possible to use different Java versions on the client 
>> and server side.
>>
>> Once you have separate your code, you can update the GWT version. My 
>> first step would be to update to GWT 2.10.0. I would do this, because to 
>> GWT 2.10.0 works with the old javax stuff on the server side and give you 
>> the opportunity to patch GXT without updating the server stuff.  (IIRC you 
>> need to patch two classes). After the patch you can move to GWT 2.11.0 and 
>> Java 11 and fix the other issues by updating versions, etc.
>>
>> Wejden Mrabti schrieb am Freitag, 26. April 2024 um 09:12:33 UTC+2:
>>
>>> thank you for your answer @craig Mitchell
>>> if i want to continue hibernate 6 , how to do launch gwt application on 
>>> java 11 ? 
>>> is it possible to continue working like this ? what do you think?
>>> Le vendredi 26 avril 2024 à 02:22:52 UTC+2, Craig Mitchell a écrit :
>>>
 It'd be hard to answer that question, as we don't have all the 
 details.  As this is a GWT forum, I'd say, migrate GWT to the latest 
 version first.  But that might actually be bad advice, just depends on 
 your 
 project.

 My gut feel is you'd be best to decouple the front end and back end 
 first.

 On Friday 26 April 2024 at 2:32:17 am UTC+10 Wejden Mrabti wrote:

> Hello GWT Users Community,
>
> I'm currently working on a large legacy application stack, using Java 
> 8, Hibernate version 5.3.20.Final, and Hibernate Search 5.11.5.Final. Our 
> frontend technology stack includes GWT version 2.8.2 and GXT version 
> 2.3.1a-gwt22. Fontend and backend arent well de-coupled.
>
> In my initial approach to modernize the application, I began by 
> migrating Hibernate to version 6.2, assuming it would be the easiest 
> step. 
> However, I encountered an issue where Hibernate 6.2 requires 
> transitioning 
> to Jakarta Persistence. When attempting to compile parts of my codebase, 
> I 
> received the following error:
>
> java.lang.UnsupportedClassVersionError: jakarta/persistence/Transient 
> has been compiled by a more recent version of the Java Runtime (class 
> file 
> version 55.0), this version of the Java Runtime only recognizes class 
> file 
> versions up to 52.0
>
> This suggests that I need to execute my code with JDK 11. However, 
> when attempting to do so, I encountered the following issue:
>
> [ERROR] Found resouce but unrecognized URL format: 
> 'jrt:/java.sql/javax/sql/DataSource.class' 
> java.lang.NoClassDefFoundError: 
> javax/sql/DataSource
>
> After reviewing your discussions in the GWT contributors group, I'm 
> questioning whether starting with the Hibernate migration is the right 
> approach. Should I instead prioritize migrating Java or perhaps GWT? I 
> would greatly appreciate your insights and advice based on your 
> experiences.
>
> Thank you,
>
> WM
>
 -- 
>> You received this message because you are subscribed to the Google Groups 
>> "GWT Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-web-tool...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit/a91eb3fa-af37-4c37-bc61-010bbd151763n%40googlegroups.com
>>  
>> 

Re: [ERROR] Unable to find 'com/google/common/collect/Collect.gwt.xml' : GWT 2.9

[Colin Alworth]

It appears that the error log you shared all boil down to missing j2objc 
and errorprone annotations from your classpath.

My concern with your moduleTemplate was simply that you left the value as 
"${project.basedir}/path/to/module/module.gwt.xml" - do you literally have 
a directory called path/to/module/ in your project's base directory? I dont 
think this is causing the problem though, nor is changing from one maven 
plugin to another, but without a complete picture of your dependencies, it 
is very hard to guess.

On Saturday, March 30, 2024 at 5:01:46 PM UTC-5 dja...@gmail.com wrote:

> Hi Colin,
>
> Thanks for your reply. Yes, that question is related. I just updated it on 
> stack overflow. I added the the javax servlet dependency and that part was 
> solved. And now I am facing another issue with the  
> *com/google/common/collect/Collect.gwt.xml 
> *module. Now you mentioned guava, I realized that I had it as a 
> dependency, however I didn't added to my gwt module xml file.  I just added 
> it and I still have a bunch of errors in the guava-gwt classes now.  I 
> tried different version of guava as well (the latest one and the 23.0 
> version).
>
> Tracing compile failure path for type 
> 'com.google.common.collect.StandardTable'
> [INFO]   [ERROR] Errors in 
> 'jar:file:/C:/Users/MyUserName/.m2/repository/com/google/guava/guava-gwt/30.1-jre/guava-gwt-30.1-jre.jar!/com/google/common/collect/StandardTable.java'
> [INFO]  [ERROR] Line 203: WeakOuter cannot be resolved to a type
> [INFO]  [ERROR] Line 566: WeakOuter cannot be resolved to a type
> [INFO]  [ERROR] Line 763: WeakOuter cannot be resolved to a type
> [INFO]  [ERROR] Line 167: CanIgnoreReturnValue cannot be resolved 
> to a type
> [INFO]  [ERROR] Line 477: WeakOuter cannot be resolved to a type
> [INFO]  [ERROR] Line 873: WeakOuter cannot be resolved to a type
> [INFO]  [ERROR] Line 150: CanIgnoreReturnValue cannot be resolved 
> to a type
> [INFO]  [ERROR] Line 593: WeakOuter cannot be resolved to a type
> [INFO]  [ERROR] Line 637: WeakOuter cannot be resolved to a type
> [INFO]  [ERROR] Line 453: CanIgnoreReturnValue cannot be resolved 
> to a type
> [INFO]  [ERROR] Line 537: WeakOuter cannot be resolved to a type
> [INFO]  [ERROR] Line 787: WeakOuter cannot be resolved to a type
> [INFO]  [ERROR] Line 838: WeakOuter cannot be resolved to a type
> [INFO]  [ERROR] Line 141: CanIgnoreReturnValue cannot be resolved 
> to a type
> [INFO]  [ERROR] Line 34: The import 
> com.google.errorprone.annotations.CanIgnoreReturnValue cannot be resolved
> [INFO]  [ERROR] Line 943: WeakOuter cannot be resolved to a type
> [INFO]  [ERROR] Line 35: The import com.google.j2objc cannot be 
> resolved
>
>  [ERROR] Aborting compile due to errors in some input files
>
> You said : *" Also, the moduleTemplate configuration looks wrong, like 
> you've left an example placeholder in the configuration?", *
> No, I don't think so, I moved the module.gwt.xml where the client/local 
> folder because the old project I want to migrate uses the old version of 
> mojo gwt-maven plugin and that's where the module is. Could that also be 
> part of my issue? I specified the path like that because the with Tbroyer 
> version, the gwt xml module file is not in the same place.
>
>
> Mnamo Jumamosi, 30 Machi 2024 saa 15:19:33 UTC-3 Colin Alworth aliandika:
>
>> This looks like the same question as 
>> https://stackoverflow.com/questions/78202341/how-to-set-up-gwt-super-dev-mode-with-the-new-gwt-maven-plugin-with-a-web-applic,
>>  
>> except with some updates - it sounds like you resolved the servlet 
>> classpath issue, can you flesh out this example a little more to show what 
>> else has happened, if that is also your question? 
>>
>> It looks like guava-gwt is somehow not on your classpath, can you verify 
>> this?
>>
>> Also, the moduleTemplate configuration looks wrong, like you've left an 
>> example placeholder in the configuration?
>>
>> On Saturday, March 30, 2024 at 1:14:40 PM UTC-5 dja...@gmail.com wrote:
>>
>>> Hi, 
>>> I am unable to build a multimodule demo project using GWT 2.9 using 
>>> @Tbroyer gwt maven plugin. The reason I am still on this GWT version is 
>>> because I am still using the Errai Framework that still depends on this 
>>> particular version of GWT. I included the module that seems to be missing 
>>> correctly and I still don't understand why it is missing.
>>>
>>> here is the error I am receiving when I run :
>>> *mvn clean install*
>>>
>>> *[I

Re: [ERROR] Unable to find 'com/google/common/collect/Collect.gwt.xml' : GWT 2.9

[Colin Alworth]

This looks like the same question as 
https://stackoverflow.com/questions/78202341/how-to-set-up-gwt-super-dev-mode-with-the-new-gwt-maven-plugin-with-a-web-applic,
 
except with some updates - it sounds like you resolved the servlet 
classpath issue, can you flesh out this example a little more to show what 
else has happened, if that is also your question? 

It looks like guava-gwt is somehow not on your classpath, can you verify 
this?

Also, the moduleTemplate configuration looks wrong, like you've left an 
example placeholder in the configuration?

On Saturday, March 30, 2024 at 1:14:40 PM UTC-5 dja...@gmail.com wrote:

> Hi, 
> I am unable to build a multimodule demo project using GWT 2.9 using 
> @Tbroyer gwt maven plugin. The reason I am still on this GWT version is 
> because I am still using the Errai Framework that still depends on this 
> particular version of GWT. I included the module that seems to be missing 
> correctly and I still don't understand why it is missing.
>
> here is the error I am receiving when I run :
> *mvn clean install*
>
> *[INFO] --- gwt:1.1.0:compile (default-compile) @ sample-client ---*
> [INFO] Loading inherited module 'net.example.sample.App'
> [INFO]Loading inherited module 'org.jboss.errai.enterprise.All'
> [INFO]   Loading inherited module 'org.jboss.errai.ioc.Container'
> [INFO]  Loading inherited module 
> 'com.google.common.collect.Collect'
> [INFO]* [ERROR] Unable to find 
> 'com/google/common/collect/Collect.gwt.xml' on your classpath; could be a 
> typo, or maybe you forgot to include a classpath entry for source?*
> [INFO] 
> 
> [INFO] Reactor Summary for Sample GWT UI 2.0-SNAPSHOT:
> [INFO]
> [INFO] Sample GWT UI .. FAILURE [ 
>  7.079 s]
> [INFO] Sample-webapp .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  8.356 s
> [INFO] Finished at: 2024-03-30T12:28:45-03:00
> [INFO] 
> 
>
> here is parts of my main pom.xml
>
> 
> 
>   
>   
> net.example.sample
> sample-client
> ${project.version}
> war
>   
>   
>   
> com.google.gwt
> gwt
> ${gwt.version}
> pom
> import
>   
>   
>
>
>
>
>
> *org.jboss.errai.bom
> errai-bom
> ${errai.version}pom
> import  *
>  
> 
>
> and parts of my module pom.xml
>
> sample-client
>   gwt-app
>
>   Sample GWT UI
>
>   
> 
>   com.google.gwt
>   gwt-dev
>   
> 
>   org.eclipse.jetty
>   apache-jsp
> 
>   
> 
>  
> 
> 
>   com.google.gwt
>   gwt-user
> 
> 
>
>
>
> *  org.jboss.errai  
> errai-javaee-all  *
> 
> 
>   org.jboss.errai
>   errai-cdi-jboss
>   runtime
> 
>   
>   
> 
>   
> net.ltgt.gwt.maven
> gwt-maven-plugin
> 
>   
> ${project.basedir}/path/to/module/module.gwt.xml
>   net.example.sample.App
>   sample
> 
>   
> 
>   
>
> and this is the module inclusion in module.gwt.xml
>
> *  *
>
> What am I missing?
> Please Advise.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/f7a5aa4c-7666-4c52-aa80-9bd9ccbb1e63n%40googlegroups.com.

Re: Problem with GWT?

[Colin Alworth]

There really isn't enough information here to guess what is happen - what 
else could have changed, like server version or configuration, any errors 
in your browser dev tools console?

On Tuesday, March 26, 2024 at 2:57:37 PM UTC-5 germ...@gmail.com wrote:

> When I access the web page, it remains blank. I tried different browsers, 
> even on different computers, and they all showed the same problem. I am 
> using the gwt-2.8.2 SDK Until a few days ago, was it working correctly? 
> The curious thing is that the website works locally, that is, it is 
> normally displayed in the browser, but when the project is uploaded it is 
> not displayed. 
> Please I need help on what can happen. Thank you so much
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/93114622-43f1-478c-96a2-15208b8c91f6n%40googlegroups.com.

Re: InvocationTargetException with null cause?

[Colin Alworth]

I'm guessing this server has been running for a while, and possibly 
seen/caught other NPEs before this point? Hotspot has an optimization where 
it stops producing stack traces for null pointer exceptions (as well as a 
few other exceptions) after it is thrown a few times (usually "many", but 
technically "two" is possible if they are rare enough and don't affect jit 
codegen) - if it is being thrown and caught a lot, the JVM will remove this 
to avoid needing to walk the stack so many times.

You can disable this behavior with the flag 
"-XX:-OmitStackTraceInFastThrow". Here's the writeup that I usually find 
when I get bothered by this issue: 
https://stackoverflow.com/a/58700744/860630. 
On Thursday, February 29, 2024 at 10:23:05 AM UTC-6 alex...@gmail.com wrote:

> Hi
>
> I am afraid this is probably more a general Java question than a pure GWT 
> question. But I am suspecting the problem somewhere in GWT server-side 
> hence asking here.
>
> I am looking for help to read my stack trace around GWT RPC 
> and InvocationTargetException Btw the system recovered after a server 
> restart, without changing anything.
>
> Stack trace was:
> ...
>
>
>
> *at java.lang.Thread.run(Thread.java:748)Caused by: 
> com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public 
> abstract xx.webapp.shared.domain.xxDTO xx.share> at 
> com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:416)*  
>
> *at 
> com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:605)*  
>
> *at 
> com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:571)*  
>
> *at 
> xxx.server.spring.SpringGwtRemoteServiceServlet.processCall(SpringGwtRemoteServiceServlet.java:120)*
>   
> 
> *... 101 common frames omittedCaused by: java.lang.NullPointerException: 
> null*
> *{call stack log ends here}*
>
> Relevant GWT code from RPC class:
>
> [image: image.png]
>
> RPC class checks for cause==null so that's not it. But then why is it not 
> showing the actual line of code where the causing exception is thrown?
>
> Regards,
> Alex
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/4b95ac47-2bc7-4901-b390-67cae94a3c6fn%40googlegroups.com.

Re: Is moving away from RPC a good idea?

[Colin Alworth]

Point 1 is a potentially a serious concern for basically any tooling that 
decouples through interprocess communication, including grpc+protobuf (with 
ostensibly "perfect backwards/forwards compatibility") - in tooling that 
doesn't explicitly force compatibility as GWT-RPC does, you have to 
implicitly handle the edge cases, like versioning each method/type in some 
way, or established rules like "reject messages that have new fields or old 
fields" (which includes never fully deleting fields), and never change the 
meaning of fields "oh, as of 3.1.2 we trim whitespace, sorry that was 
significant for you"). GWT-RPC is a lot grumpier about it - change fields 
of any one type used by any one method in your service, and the entire 
service is invalid. Poof, you know instantly that something is invalid, and 
should update to continue. 

A disciplined approach like what gRPC forces, where fields added must 
always be safe to skip and fields removed must never change the meaning of 
the message ends up requiring design-time work to enforce, and those 
notions can apply to other tools as well. Only add service calls, version 
the service when any DTO/message type changes, and keep backwards 
compatiblity for old versions for a release or two. As long as you upgrade 
your servers past these breaking points slightly less often than the 
intervals over which clients get updates, this can't go wrong (and applies 
cleanly for gwt-rpc as well). Among other projects, the envoy proxy's XDS 
service is very aggressive about this - it works, and ensures you can 
aggressively evolve the services, but it sure is a pain for XDS clients to 
keep up with.

 In the middle somewhere is to do what most teams do, and take a "eh, this 
probably isn't _that_ important to miss" approach, and a few calls/cases 
may fail from time to time. 

Going back to envoy briefly, XDS makes it possible for the proxy to change 
endpoints it supports on the fly based on service calls to update the 
cluster configuration. For long-running streams it can make sense to simply 
say "Add new cluster member Y, and when you are done with all active 
connections to instance X, don't allow future connections to it". GWT-RPC 
isn't streaming out of the box (our GWT-RPC fork is, and is intended to be 
j2cl/jvm/android/etc compatible), so you need to introduce "sessions" 
somehow into the vocabulary, or add metadata to responses 
("X-FooSoft-Version: 4" means if you speak version 3, time to upgrade, or 
"X-Deprecated: true" means you're out of date and should update soon, etc) 
that the client should always check, and assume that rotation can happen 
over some range of hours or days.

On Friday, February 9, 2024 at 9:36:37 AM UTC-6 alex...@gmail.com wrote:

> Thanks for that answer Jens. Makes perfect sense.
>
> Regarding point 1, I am thinking about a more seamless upgrade process 
> that minimizes client interruption. Such that old clients can remain 
> working on "old" server versions for a while, while new clients work on new 
> servers in parallel, until all old clients are migrated in a controlled 
> process. Once no old clients are connected any more, the old servers are 
> shut down and the upgrade process is completed.
>
> Is there any suggested standard approach (e.g. Load Balancer Setups, 
> Client-Server Interface Versioning) to achieve this? Anyone doing this 
> successfully?
>
> Freundliche Grüsse,
> Alexander Karg
>
>
>
> On Mon, Jan 15, 2024 at 5:26 PM Jens  wrote:
>
>>
>> Some mention "some annoying downsides" or "is imperfect in a lot of ways" 
>> regarding gwt-rpc. What are does? 
>>
>>
>> 1. Client and server always need to be in sync because of serialization 
>> policy. So a user must reload the web app if you redeploy your application 
>> and have modified shared classes. 
>> 2. If you want to use J2CL in the future you should not use it.
>> 3. You can only use it with GWT clients unless you reimplement the wire 
>> format in other languages / applications. Only unofficial information about 
>> the wire format exists. 
>> 4. No async servlet support
>> 5. Command pattern doesn't work well with GWT-RPC because you cannot code 
>> split the client side serialization data. So your initial or leftover 
>> fragment contains everything that goes over the wire. Code splitting only 
>> works well if you have one GWT-RPC service per code split condition.
>>
>> -- 
>>
> You received this message because you are subscribed to the Google Groups 
>> "GWT Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-web-tool...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit/cc4b2a17-a072-4685-b138-34f31e46cc5fn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you 

Re: GWT Eclipse Plugin 4 Problem

[Colin Alworth]

There is a pending patch for this at 
https://github.com/gwt-plugins/gwt-eclipse-plugin/pull/475. You should be 
able to pull and build this to get working again on the very latest Eclipse 
versions - and if you do, leave a comment, a code review, etc, and we can 
get this merged more expediently. 

GWT is largely a volunteer project, the GWT Plugin for Eclipse doubly so - 
and while the GWT contributor pool is small, the GPE pool is more of a 
puddle. We're trying to raise interest in this among users and 
contributors, but we can't drag people to work on code or force them to pay 
for work to get done. The GPE tooling has never formally been part of the 
GWT project (first owned entirely by the App Engine team at Google if I'm 
not mistaken, then ran as its own github org for many years), but we're 
trying to bring these pieces in line as we grow.

Additionally, Eclipse marketshare isn't what it once was - I can't remember 
the last time I saw a project that ran better on Eclipse than IntelliJ. 
This is not intended as a slight towards anyone who is more productive with 
Eclipse, only as a remark that with fewer interest, it is hard to keep the 
project going.

Finally, the workaround is straightforward - 2023-09 was the latest as of 
60 days ago, falling back to it will likely not destroy any development 
workflows.


On Wednesday, January 31, 2024 at 8:09:53 PM UTC-6 Fred Andrews wrote:

> No response to this man's issue after 6 weeks and I just hit the same 
> problem.  This is shocking.  
>
> The plugin cannot be installed.   Is GWT a dead product?
>
> On Monday, December 11, 2023 at 2:12:30 PM UTC-6 Bob Lacatena wrote:
>
>> Hey. My coworker and I ran into trouble installing the GWT plugin on 
>> Eclipse 2023-12 (worked fine on 2023-09, so this isn't urgent, I'm just 
>> letting you know).
>>  
>> A couple of weeks ago I got a new Mac, installed Eclipse 2023-09 and the 
>> GWT plugin, no problem.
>>
>> My coworker just got a new PC (Windows 11), and got Eclipse 2023-12 (just 
>> released), tried to install the GWT plugin as I did, and could not.  It 
>> first required JustJ Adoptium OpenJDK 21.
>>
>>   JustJ Adoptium OpenJDK Hotspot JRE Complete 21.0.1.v20231028-0937 
>> org.eclipse.justj.openjdk.hotspot.jre.full.feature.group Eclipse JustJ
>>
>> After doing so, getting the GWT plugin still failed.  First it says 
>> "Cannot complete operation.  Computing alternate solutions, may take a 
>> while: X/15"
>>
>> Then it tells you it failed, giving you a chance to select other features 
>> (but there is only one).
>>
>> I confirmed that this also happens with 2023-12 on my Mac.
>>
>> My co-worker dropped back to 2023-09 on his PC, and it installed fine.
>>
>> Just an FYI.
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/d7165f83-d53f-44dd-8996-4dc76a0418fen%40googlegroups.com.

Re: "Unload event listeners are deprecated" browser error

[Colin Alworth]

It looks like the purpose of registering the unload handler for any Window 
event is to avoid IE6-10 era memory leaks. From the notes on the MDN page, 
removing those other handlers will break the page when the bfcache is in 
use, but our use of the unload handler will opt GWT pages out.

The simplest fix appears to be to stop initializing the unload event 
tracking for resize/scroll events, and "let" those leak (which they won't, 
because IE in all forms is really-actually-totally-dead this time, right?). 
Next unload/beforeunload should be decoupled, so that each can be 
initialized separately. Then applications can remove their own usage of 
unload as they wish, but we should probably deprecate this event handler 
method (not the event and handler itself) as well.

I have filed https://github.com/gwtproject/gwt/issues/9908 to track this.

On Thursday, January 25, 2024 at 11:38:53 AM UTC-6 Thomas Broyer wrote:

> Yes: https://developer.mozilla.org/en-US/docs/Web/API/Window/unload_event
> Apparently, this happens when you use Window.addXxxHandler (and for 
> instance the default PlaceController's delegate calls 
> Window.addClosingHandler, which registers an unload handler but is only 
> interested in the beforeunload event)
>
> On Thursday, January 25, 2024 at 5:18:39 PM UTC+1 ofr...@gmail.com wrote:
>
>> Hello.
>>
>> Browsers running our GWT application (version 2.11) have recently (this 
>> week) started reporting errors like this one:
>>
>> [{"age":41550,"body":{"columnNumber":192,"id":"UnloadHandler
>> ","lineNumber":3210,"message":"Unload event listeners are deprecated and 
>> will be removed.","sourceFile":"ourmodule-0.js"},"type":"deprecation","
>> url":"oururl","user_agent":"Mozilla/5.0 (Linux; Android 10; K) 
>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Mobile 
>> Safari/537.36"}]
>>
>> Any idea about why is this happening?  Is GWT using a deprecated browser 
>> feature?
>>
>> Thanks!
>> Oscar
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/b02836a4-290b-4691-ac29-d158bc08c997n%40googlegroups.com.

[gwt-contrib] Re: Infinite loop at compile time

[Colin Alworth]

Thanks for reporting - perhaps better for the bug tracker, and indeed we do 
this (or something like it) filed already, see 
https://github.com/gwtproject/gwt/issues/9840.

Your email title says that this is a compile time infinite loop, but then 
the body suggests that it was a runtime error. If it were to be exhibited 
at runtime, it would almost certainly be a stackoverflow rather than 
looping forever (barring some sort of tail call optimization). The actual 
loop that you're seeing is waaay up the stack in 

at 
com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.optimizeJsLoop(JavaToJavaScriptCompiler.java:1001)

where the compiler decides to optimize until it reaches your optimization 
level, or until nothing changes. While SDM stands for "Super Dev Mode", it 
can also be understood to mean "Super Draft Mode", so the compiler builds 
as quickly and cheaply as possible, letting your app escape with very 
little optimization. This means that in SDM, you will not get stuck in this 
loop - the optimization loop won't run at all (see one frame up, 
shouldOptimize will return false), and you'll instead experience a 
stackoverflow at runtime.

I didn't continue investigation of the problem further yet, but the linked 
ticket does have some analysis to consider.
On Monday, January 22, 2024 at 8:30:50 AM UTC-6 Paul Robinson wrote:

> I just found an infinite loop while running the GWT compiler.
>
> There was a trivial bug in my code which resulted in an infinite loop at 
> *runtime*. This is a method that was calling itself recursively. It was 
> inside a generic class, and the method had a single line that was something 
> like this:
>
> public class A extends C {
> public static  A getA(D d, E e, F f) {
> return getA(d, e, null);
> }
> }
>
> I have been running in dev mode with it like this, but not hitting this 
> code so I didn't notice the infinite loop.
>
> Wanting to test GWT 2.11.0, I switched from GWT 2.10.0 and did a full GWT 
> compile. The interesting thing is that the GWT compile also hit an infinite 
> loop. Or rather, it was apparently infinite. I stopped it after 50 minutes, 
> where it would normally complete in about about 90 seconds. I dropped back 
> to 2.10.0, and found the same behaviour. So it's not caused by the new 
> release.
>
> Fixing the bug in my code meant it then compiled properly (in both 2.11.0 
> and 2.10.0).
>
> Is this interesting enough to warrant further investigation? This is code 
> inside a large application, so isolating a simple example that demonstrates 
> it might not work easily.
>
> FWIW there's a stack trace taken while stuck in the loop, compiling with 
> 2.11.0 here: https://pastebin.com/qckpswRD
>
> Paul
>
>

-- 
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/58e74afc-7677-4a92-8895-880d884cd802n%40googlegroups.com.

Re: Running GWT 2.4.0 using JDK 17

[Colin Alworth]

Without knowing the specific constraints you're under, and the specific 
changes you've made, this will be very hard to debug. Feel free to contact 
me (co...@vertispan.com) off-list if this isn't appropriate to share 
publicly, and we can see about helping you resolve this by making the 
changes you need, or helping you to understand what they might entail so 
you can do it yourself.

The only interesting thing I see in the log so far is that the version of 
guava in use can't (reflectively, I assume) access some threadlocal 
details. As of GWT 2.4, the guava version was 6.0, immediately after that 
release it was updated to 10.0.1. Current GWT uses 19.0. Turn off your JVM 
logging to reduce the noise a bit.

Understanding the constraints you're under will help to offer a path 
forward - and the changes you've made so far will clarify what else might 
need to be done, based on the history of GWT. This is the kind of problem I 
like solving, but I don't necessarily have a lot of free time to play with 
it, so a clear picture is important. We know that what you are doing is 
broadly possible - the limiting factor will be the specific requirements 
you have to consider it successful.



On Tuesday, January 16, 2024 at 7:55:45 AM UTC-6 anjana@gmail.com wrote:

> Colin,
>
> As mentioned earlier due to some unavoidable constraints we are unable to 
> upgrade GWT to its latest version and so we are trying out this option. I 
> have attached the GWT.2.4.0 ant build logs and GWT error related build 
> logs. I am not sure if this gonna work but just wanted to give a try and if 
> it works it will be helpful.  Thank you very much!
>
>
> Regards,
> Anjana
>
> On Tuesday, January 16, 2024 at 6:17:08 PM UTC+5:30 Colin Alworth wrote:
>
> Unfortunately, there isn't enough information to help you without redoing 
> the work you've done - most of your log looks like the jvm's own internal 
> logging, which doesn't tell me anything right away at least.
>
> What commands exactly did you use to build, and what changes did you make, 
> how did you validate that the jars you created were able to be used at all, 
> how did you ensure that the changes you made would solve the problems you 
> are after? Can you share the full build log - for certain "Unable to find 
> ..." is not the first line of logging that GWT itself emitted.
>
> In the event you are cherry-picking specific GWT commits since 2.4, to add 
> support for newer JVMs (which is to say changes that are known to add 
> support for newer JDKs), why not simply update to a newer GWT version? 
> Wouldn't it be better to use a version built and tested for what you 
> intend, than to make a custom fork of a 12 year old version?
>
> Quick testing locally shows at least that 2.8.2 will run on Java 17 for 
> the Hello sample app, which is still pretty old, having been published in 
> 2017. In the event you aren't able to update to latest, what about just 
> updating to something not quite as old, but validated to work on Java9+?
>
> On Tuesday, January 16, 2024 at 6:26:19 AM UTC-6 anjana@gmail.com 
> wrote:
>
> Hi Colin,
>
> Thanks for the response!
> As an initial step I am try to build the GWT SDK jars from source code by 
> following the instructions provided in this link - 
> https://github.com/gwtproject/gwt?tab=readme-ov-file
>
> With few corrections in GWT.2.4.0 source code was able to build jars 
> successfully with JDK 17 and also tried with JDK.1.8 (no code change made) 
> by using command ant clean dist-dev with -Dgwt.tools  from CLI as mentioned 
> in the above link.  But when I use these generated jars(gwt-dev.jar, 
> gwt-user.jar, gwt-servlet.jar, gwt-servlet-deps.jar, 
> requestfactory-apt.jar, requestfactory-client.jar, 
> requestfactory-server.jar, requestfactory-client+src.jar, 
>  requestfactory-server+src.jar, requestfactory-client-src.jar, 
>  requestfactory-server-src.jar) into my application, I am getting below 
> error-
>
> Error trace-
>
>  [java] [1.574s][info][class,load] 
> com.google.gwt.dev.javac.CompilationProblemReporter source:  
>
> [java] [1.575s][info][class,load] 
> java.lang.invoke.LambdaForm$MH/0x7fe964144000 source: 
> __JVM_LookupDefineClass__
>
>  [java] [1.575s][info][class,load] 
> java.lang.invoke.LambdaForm$MH/0x7fe964144400 source: 
> __JVM_LookupDefineClass__
>  [java] [1.576s][info][class,load] 
> java.lang.invoke.LambdaForm$MH/0x7fe964144800 source: 
> __JVM_LookupDefineClass__
>  [java] [1.576s][info][class,load] 
> java.lang.invoke.LambdaForm$MH/0x7fe964144c00 source: 
> __JVM_LookupDefineClass__
>  [java]
> *[ERROR] Unable to find type 'java.lang.Object'* [java] 
> [1.577s][info][class,load] com.google.gwt.dev.util.Messages 

Re: Running GWT 2.4.0 using JDK 17

[Colin Alworth]

Unfortunately, there isn't enough information to help you without redoing 
the work you've done - most of your log looks like the jvm's own internal 
logging, which doesn't tell me anything right away at least.

What commands exactly did you use to build, and what changes did you make, 
how did you validate that the jars you created were able to be used at all, 
how did you ensure that the changes you made would solve the problems you 
are after? Can you share the full build log - for certain "Unable to find 
..." is not the first line of logging that GWT itself emitted.

In the event you are cherry-picking specific GWT commits since 2.4, to add 
support for newer JVMs (which is to say changes that are known to add 
support for newer JDKs), why not simply update to a newer GWT version? 
Wouldn't it be better to use a version built and tested for what you 
intend, than to make a custom fork of a 12 year old version?

Quick testing locally shows at least that 2.8.2 will run on Java 17 for the 
Hello sample app, which is still pretty old, having been published in 2017. 
In the event you aren't able to update to latest, what about just updating 
to something not quite as old, but validated to work on Java9+?

On Tuesday, January 16, 2024 at 6:26:19 AM UTC-6 anjana@gmail.com wrote:

> Hi Colin,
>
> Thanks for the response!
> As an initial step I am try to build the GWT SDK jars from source code by 
> following the instructions provided in this link - 
> https://github.com/gwtproject/gwt?tab=readme-ov-file
>
> With few corrections in GWT.2.4.0 source code was able to build jars 
> successfully with JDK 17 and also tried with JDK.1.8 (no code change made) 
> by using command ant clean dist-dev with -Dgwt.tools  from CLI as mentioned 
> in the above link.  But when I use these generated jars(gwt-dev.jar, 
> gwt-user.jar, gwt-servlet.jar, gwt-servlet-deps.jar, 
> requestfactory-apt.jar, requestfactory-client.jar, 
> requestfactory-server.jar, requestfactory-client+src.jar, 
>  requestfactory-server+src.jar, requestfactory-client-src.jar, 
>  requestfactory-server-src.jar) into my application, I am getting below 
> error-
>
> Error trace-
>
>  [java] [1.573s][info][class,load] 
> com.google.gwt.dev.javac.TypeOracleMediator$TypeOracleMediatorResolver 
> source: 
> file:/scratch/home/aarmugam/SDM_java17/sryadava_Ammolite_linux/nnc/core/ACMEConsole/WEB-INF/lib/gwt-dev.jar
>  [java] [1.574s][info][class,load] 
> com.google.gwt.dev.javac.CompilationProblemReporter source: 
> file:/scratch/home/aarmugam/SDM_java17/sryadava_Ammolite_linux/nnc/core/ACMEConsole/WEB-INF/lib/gwt-dev.jar
>  [java] [1.575s][info][class,load] 
> java.lang.invoke.LambdaForm$MH/0x7fe964144000 source: 
> __JVM_LookupDefineClass__
>  [java] [1.575s][info][class,load] 
> java.lang.invoke.LambdaForm$MH/0x7fe964144400 source: 
> __JVM_LookupDefineClass__
>  [java] [1.576s][info][class,load] 
> java.lang.invoke.LambdaForm$MH/0x7fe964144800 source: 
> __JVM_LookupDefineClass__
>  [java] [1.576s][info][class,load] 
> java.lang.invoke.LambdaForm$MH/0x7fe964144c00 source: 
> __JVM_LookupDefineClass__
>  [java]
> *[ERROR] Unable to find type 'java.lang.Object'* [java] 
> [1.577s][info][class,load] com.google.gwt.dev.util.Messages source: 
> file:/scratch/home/aarmugam/SDM_java17/sryadava_Ammolite_linux/nnc/core/ACMEConsole/WEB-INF/lib/gwt-dev.jar
>  [java]   *[ERROR] Hint: Check that your module inherits 
> 'com.google.gwt.core.Core' either directly or indirectly (most often by 
> inheriting module 'com.google.gwt.user.User')*
>  [java] [1.578s][info][class,load] 
> java.util.IdentityHashMap$KeyIterator source: shared objects file
>  [java] [1.578s][info][class,load] java.io.RandomAccessFile$1 source: 
> shared objects file
>  [java] [1.579s][info][class,load] 
> java.util.prefs.FileSystemPreferences$10 source: jrt:/java.prefs
>  [java] [1.579s][info][class,load] 
> java.util.prefs.FileSystemPreferences$12 source: jrt:/java.prefs
>  [java] [1.579s][info][class,load] 
> java.util.prefs.FileSystemPreferences$11 source: jrt:/java.prefs
>
>
> I checked many blogs on the similar error where it was mentioned the root 
> cause for this issue was because of classpath mistake.  I am running my 
> application ant build from CLI and also I have verified that all the 
> required jars are present in classpath. Could you please guide me here to 
> tackle this issue? Please note I am  also *facing  same issue when I 
> build jars with JDK.1.8 without any code change in GWT.2.4.0 source code*.
>
> GWT.2.4.0 source code downloaded from -
>  https://github.com/gwtproject/gwt/releases/tag/2.4.0 
> <https://github.com/gwtproject/gwt/releases/tag/2.4.0>
> tools - https://g

Re: Announcing GWT 2.10.1 and 2.11 releases

[Colin Alworth]

Craig, you’ll need to change to the -jakarta artifacts. That is, for 
RemoteServiceServlet, instead of gwt-servlet.jar, use gwt-servlet-jakarta.jar, 
and the class is in the .rpc.jakarta package to ensure there is no possibility 
of referencing the wrong type. Change both the jar and your imports to use it. 

Note that this is not compatible with running your jakarta-servlet app inside 
dev mode, but you will need to run your own server separately from dev mode. 

-- 
  Colin Alworth
  co...@colinalworth.com


On Sat, Jan 13, 2024, at 7:54 PM, Craig Mitchell wrote:
> Awesome!  Thank you GWT team!
> 
> Regarding:
> **
> *> Added release artifacts for jakarta.servlet packages for both 
> RequestFactory and GWT-RPC.*
> 
> When I look at com.google.gwt.user.server.rpc.RemoteServiceServlet, it's 
> still using javax.servlet.http.HttpServlet.  So calls like 
> getThreadLocalRequest() return javax.servlet.http.HttpServletRequest and not 
> jakarta.servlet.http.HttpServletRequest.  Is there another version of 
> RemoteServiceServlet I can use that uses the jakarta classes?
> 
> Thanks.
> On Friday 12 January 2024 at 1:28:05 am UTC+11 Filipe Sousa wrote:
>> 
>> 
>> On Tuesday, January 9, 2024 at 9:36:08 PM UTC Colin Alworth wrote:
>>> I'm excited to announce the release of 2.10.1 and 2.11.0! This is our 
>>> second release under the new groupId, be sure when you update to change 
>>> away from "com.google.gwt", as it will not get more updates.
>>> 
>>> If you use GWT-RPC and JPA/JDO annotations in your project, we strongly 
>>> suggest updating at least to 2.10.1 as soon as possible. To ensure that 
>>> vulnerable projects are aware of any problem, compile warnings will be 
>>> emitted if a problem is detected, and the server will default to not 
>>> allowing any vulnerable RemoteService instances. See 
>>> https://github.com/gwtproject/gwt/issues/9709 for information on the issue, 
>>> how we're responding to it, and how any additional follow-up might look.
>>> 
>>> Other highlights:
>>>  • Transitioned to GitHub pull requests for new contributions, with nightly 
>>> builds running on GitHub Actions.
>>>  • Added release artifacts for jakarta.servlet packages for both 
>>> RequestFactory and GWT-RPC.
>>>  • Tested support for running on Java 21. This is likely to be the final 
>>> minor release series to support running on Java 8.
>>>  • Updated JRE emulation to support Java 11 for Collections, streams, and 
>>> more.
>>> See https://github.com/gwtproject/gwt/releases/tag/2.11.0 or 
>>> https://www.gwtproject.org/release-notes.html#Release_Notes_2_11_0 for 
>>> complete release notes.
>>> 
>>> This release wouldn't have been possible without help from so many 
>>> contributors, including developers, testers, and sponsors. A short list of 
>>> the teams and individuals that directly brought us this release: Juan Pablo 
>>> Gardella, Rocco De Angelis, Frank Hossfeld, Manfred Tremmel, Jim Douglas, 
>>> Zbynek Konecny, Piotr Lewandowski, Axel Uhl, Thomas Broyer, Filipe Sousa, 
>>> Sandra Parsick, Jens Nehlmeier, Schubec GmbH, Tom Sawyer Software, 
>>> Insurance Insight Inc. Join us on the issue tracker 
>>> <https://github.com/gwtproject/gwt/issues> or at our OpenCollective page 
>>> <https://opencollective.com/gwt-project> to help make future releases 
>>> possible.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/google-web-toolkit/cc9f18b3-1bfd-43f0-b2bc-e694a04f6fb5n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/google-web-toolkit/cc9f18b3-1bfd-43f0-b2bc-e694a04f6fb5n%40googlegroups.com?utm_medium=email_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/bb932383-0db9-45c5-a8f1-74bbc4f619eb%40app.fastmail.com.

Re: Is moving away from RPC a good idea?

[Colin Alworth]

With 2.11 released, GWT-RPC (and RequestFactory) work on jakarta.servlet. 
There are no specific improvements that I'm aware of that require updating 
beyond the Servlet API 5.0, which is what gwt-servlet-jakarta uses.

I _believe_ that RestyGWT relies on Generators, so might make an eventual 
move to J2CL difficult, if that happens to be on your radar.

My personal experience is that GWT-RPC is imperfect in a lot of ways, but 
for the kinds of things that GWT excels at, I still often find it to be 
better than the other options. It is explicitly for GWT clients, and it 
uses the shared DTO types as the source of truth for how to de/serialize, 
so it ensures a certain consistency that way. 

JSON-over-HTTP (whether actual REST or not) has me missing real object 
graphs, numerical precision (somehow JSON's spec allows for infinite 
precision for ints/floats, but forgot to add infinity/nan? and yet the JS 
runtime cuts off that precision to what fits in an IEEE754 64bit float...), 
no date/time support, and not terribly efficient for large payloads. It 
does a pretty great job of being okay in any language/runtime though, but 
it isnt hard to get subtle serialization differences, and end up needing 
not just a schema to share (openapi/swagger/etc can help with this), but 
also deciding what those conventions will be. JSON can also work well over 
other transports, such as websockets - same basic limitations as with HTTP, 
but depending on your use case could well be worth examining.

I've had a lot of close-up experiences with gRPC lately (protobufs, 
flatbufs, and Apache Arrow's Flight protocol in GWT), and I nearly like it, 
aside from the abysmal support for browser clients. gRPC offers some tools 
that at least REST doesn't - streaming data being the main one, and overt 
RPC calls rather than relying on consistent definitions of REST verbs 
(which is wonderful when done right, but most teams using "REST" are 
usually just "JSON-over-HTTP RPC"). This could be (and may yet be someday) 
a whole article by itself someday, but gRPC is outright incompatible with 
browsers without first translating to gRPC-web usually requiring a proxy 
between server and JS client), the default JS client can't do stream server 
data with binary formatting (only text formatting allowed), and the browser 
itself can't handle bidirection streaming at all. But you define your 
services and types outside of any language, each language gets bindings 
generated for it which will be consistent with all other languages, and, if 
used properly, clients/servers are forwards and backwards compatible with 
each other. Some niceties like subclasses, nullable collections and strings 
aren't available or at least hard to reproduce in a recognizable way. There 
is also no good code generation for GWT at this time, so we've been 
operating using generated jsinterop from the grpc and proto libraries and 
generated code, with decent success. If you are interested in pursuing 
gRPC, we have worked on a servlet (jakarta and javax) implementation of 
gRPC, and a servlet filter implementation that in-process handles the 
grpc-web translation. We also worked up a websocket implementation that 
behaves like an http2 transport, with multiple concurrent streams running 
on it, even over http/1.1.

One final note: we forked gwt-rpc  a 
few years ago to provide a binary wire format and built-in websocket 
support. The focus of our use case was on "struct-like" types, avoiding 
most collections and polymorphism, but the implementation can still handle 
most situations that regular GWT-RPC can deal with, but without writing to 
utf-8 strings (offering a significant performance improvement for large 
payloads), and allowing interop with non-GWT clients (JVM and android 
clients are provided, TeaVM works in our experiments, but hasn't been 
published, and there are closed source c++ and c# clients as well). I 
haven't updated this to use jakarta.servlet yet, but I imagine it would 
take less than a day to start and finish it.

On Wednesday, January 10, 2024 at 1:45:31 PM UTC-6 Michael Joyner wrote:

> You should investigate the DominoKit project. They have a much more 
> up-to-date JSON/Jackson-ish implementation.
>
> Ref: https://github.com/DominoKit/domino-rest
>
>
>
>
> On 1/10/24 11:26, Christian Hebert wrote:
>
> Hi guys, I've seen the changes in the new release regarding jakarta 
> servlets, which is great, it's a step toward jakarta but to this day,  GWT 
> is still based on the Servlet API 3.1. 
>
> Prior of seeing that change, I tried to move away from RPC calls and use 
> http requests instead. I found a nice library called RestyGWT (
> https://resty-gwt.github.io/) who can really simplify the process of 
> handling json data from/to a Rest API.
>
> So I converted my GWT remote servlets to a Rest API, made a few minor 
> changes in my client code and voilà, I was able to deploy it on a Jakarta 
> Application 

Announcing GWT 2.10.1 and 2.11 releases

[Colin Alworth]

I'm excited to announce the release of 2.10.1 and 2.11.0! This is our 
second release under the new groupId, be sure when you update to change 
away from "com.google.gwt", as it will not get more updates.

If you use GWT-RPC and JPA/JDO annotations in your project, we strongly 
suggest updating at least to 2.10.1 as soon as possible. To ensure that 
vulnerable projects are aware of any problem, compile warnings will be 
emitted if a problem is detected, and the server will default to not 
allowing any vulnerable RemoteService instances. See 
https://github.com/gwtproject/gwt/issues/9709 for information on the issue, 
how we're responding to it, and how any additional follow-up might look.

Other highlights:

   - Transitioned to GitHub pull requests for new contributions, with 
   nightly builds running on GitHub Actions.
   - Added release artifacts for jakarta.servlet packages for both 
   RequestFactory and GWT-RPC.
   - Tested support for running on Java 21. This is likely to be the final 
   minor release series to support running on Java 8.
   - Updated JRE emulation to support Java 11 for Collections, streams, and 
   more.

See https://github.com/gwtproject/gwt/releases/tag/2.11.0 or 
https://www.gwtproject.org/release-notes.html#Release_Notes_2_11_0 for 
complete release notes.

This release wouldn't have been possible without help from so many 
contributors, including developers, testers, and sponsors. A short list of 
the teams and individuals that directly brought us this release: Juan Pablo 
Gardella, Rocco De Angelis, Frank Hossfeld, Manfred Tremmel, Jim Douglas, 
Zbynek Konecny, Piotr Lewandowski, Axel Uhl, Thomas Broyer, Filipe Sousa, 
Sandra Parsick, Jens Nehlmeier, Schubec GmbH, Tom Sawyer Software, 
Insurance Insight Inc. Join us on the issue tracker 
 or at our OpenCollective page 
 to help make future releases 
possible.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/17887d7a-ee71-4dd6-bd21-8365a91536dbn%40googlegroups.com.

Re: Can we uplift GWT2.4.0 to GWT 2.10 directly

[Colin Alworth]

Check out the recent thread 
https://groups.google.com/g/google-web-toolkit/c/3z8KB_5u7ig - most of the 
discussion applies here too. That is, without knowing what libraries you 
use, what application code you've written, what error messages you get from 
attempting either running the app directly on Java 17 or from updating to 
GWT 2.10.0 first, it will be hard to guess what problems you might run in 
to. GWT tries to keep backwards compatibility where possible, but in 12 
years there are going to be a few breaking change to consider in GWT itself 
(and without knowing what other application or library code in your 
project, it would be impossible to guess what else might have broken along 
the way).

Can you share more detail about what you've tried so far?

On Friday, January 5, 2024 at 4:07:41 AM UTC-6 bharadwajja...@gmail.com 
wrote:

> Hello everyone,
> We needed to run our application on Java 17 because we were using GWT 
> 2.4.0 in our application code for some reason. Based on the release notes, 
> I can see that Version 2.10 is supported for Java 17. 
> We are now using GWT 2.4.0 for our application on Java 8, thus my question 
> is: is it possible to upgrade to GWT 2.10 directly or will I would run into 
> problems if i do so?
>
> Many thanks ahead of time!
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/a70c33bb-ed20-4df6-9522-b864f1c6091en%40googlegroups.com.

Re: Strategies for dealing with large number of languages?

[Colin Alworth]

Apologies, dumb typo right in the first line: It is _no longer_ singly 
threaded by the time permutations are being built. I hope the rest is more 
accurate, please feel free to call me out on other dumb mistakes :).

On Wednesday, January 3, 2024 at 9:29:20 PM UTC-6 Colin Alworth wrote:

> First, there's no magic - the compiler is pretty memory/cpu intensive, but 
> by the time permutations are being built, it is singly threaded. Unless 
> you've got a ton of cache and bandwidth to ram, "not scaling linearly" 
> makes a lot of sense no matter what your application is - you're probably 
> able to saturate access to memory before you can keep your CPUs busy. 
> Additionally, I'm not sure exactly what "vCPU" means these days, but the 
> last time I checked cloud vendors were using hyperthreading/etc to let a 
> given "core" work on more than one thread at a time, and appear to be 
> multiple cores to software. Ostensibly this lets the CPU handle more than 
> one instruction at the same time... but you're still choking on memory 
> access, loading more data into cache as needed to chase those pointers. 
>
> So, on a given set of hardware, you're probably able to find a limit where 
> you are no longer scaling linearly, and another limit somewhat above that 
> where you're no longer building any faster. 
>
> A few questions, that either may help the discussion along, or might help 
> you to weigh your options:
>
>- What happens if you profile the compiler like a normal Java 
>application - is the heap too big (30GB is a bit of a magic number to stay 
>below when it comes to compressed references 
><https://shipilev.net/jvm/anatomy-quarks/23-compressed-references/>) 
>or too small (a bit more headroom might make it possible to get more work 
>done)? 
>- What does your CPU usage look like - is the process actually scaling 
>to use the threads you have?
>- Any other oddities in your profiling report? When we look at 
>long-lived GWT applications, it isn't uncommon for us to find far too many 
>split points, which eat an amazing amount of build time to produce even if 
>they have very little effect. The compiler can be "asked" to guess for you 
>which splitpoints are not worth having, but it is worth auditing this or 
>other parts of the build to see what else could be going on.
>
> Now some GWT specific points, rather than general JVM points: 
>
>- What do you gain from those permutations? Taking an extreme example, 
>what happens if you collapse the entire application, 48 permutations, into 
>one single super-permutation - how much bigger is the app? How much slower 
>is it? What if you just collapse mobile vs desktop (I'd guess that mobile 
>is smaller than desktop, but smaller enough to matter?), or collapse 
>languages in groups of, say 4-8 - do you add 20% to the total compiled 
>size, or 1%?
>- Do you always need separate permutations? For acceptance testing, 
>you likely want the same build that would go into a production release, 
> but 
>maybe it is okay to add 15 minutes to those build times, but for "does 
> this 
>PR build?" or "post-merge, does main still pass tests?", you might be able 
>to support a subset of values, or just a collapsed set, saving time, but 
>producing somewhat larger output.
>- Any other configuration you've experimented with? As you alluded to, 
>you can split the process up when building permutations via the 
>"gwt.jjs.permutationWorkerFactory" system property. In short, this is 
>customizable to not just decide "all work stays in-process" or "fork 
>another JVM per permutation (and tune memory usage carefully)", but also 
>how many workers come from each source. The default (see 
>PermutationWorkerFactory for specifics) is to run 
>both ThreadedPermutationWorkerFactory for the permutations, then 
>ExternalPermutationWorkerFactory for the next, etc. The -localWorkers 
>option and "gwt.jjs.maxThreads" system property will further control how 
>work is divided. 
>- Javadoc for ExternalPermutationWorkerFactory indicates that it runs 
>CompilePermsServer instances, but the isLocal method still returns true. A 
>custom worker factory can also be written to not just write work to disk 
>and handle it in a forked JVM, but even copy to another machine and 
>communicate with it remotely.
>
> I _suspect_ you won't get too far into the weeds with this before finding 
> a happy medium with small-enough compiled output and fast enough 
> development/CI builds, but that at least covers where I would get sta

Re: Strategies for dealing with large number of languages?

[Colin Alworth]

First, there's no magic - the compiler is pretty memory/cpu intensive, but 
by the time permutations are being built, it is singly threaded. Unless 
you've got a ton of cache and bandwidth to ram, "not scaling linearly" 
makes a lot of sense no matter what your application is - you're probably 
able to saturate access to memory before you can keep your CPUs busy. 
Additionally, I'm not sure exactly what "vCPU" means these days, but the 
last time I checked cloud vendors were using hyperthreading/etc to let a 
given "core" work on more than one thread at a time, and appear to be 
multiple cores to software. Ostensibly this lets the CPU handle more than 
one instruction at the same time... but you're still choking on memory 
access, loading more data into cache as needed to chase those pointers. 

So, on a given set of hardware, you're probably able to find a limit where 
you are no longer scaling linearly, and another limit somewhat above that 
where you're no longer building any faster. 

A few questions, that either may help the discussion along, or might help 
you to weigh your options:

   - What happens if you profile the compiler like a normal Java 
   application - is the heap too big (30GB is a bit of a magic number to stay 
   below when it comes to compressed references 
   ) or 
   too small (a bit more headroom might make it possible to get more work 
   done)? 
   - What does your CPU usage look like - is the process actually scaling 
   to use the threads you have?
   - Any other oddities in your profiling report? When we look at 
   long-lived GWT applications, it isn't uncommon for us to find far too many 
   split points, which eat an amazing amount of build time to produce even if 
   they have very little effect. The compiler can be "asked" to guess for you 
   which splitpoints are not worth having, but it is worth auditing this or 
   other parts of the build to see what else could be going on.

Now some GWT specific points, rather than general JVM points: 

   - What do you gain from those permutations? Taking an extreme example, 
   what happens if you collapse the entire application, 48 permutations, into 
   one single super-permutation - how much bigger is the app? How much slower 
   is it? What if you just collapse mobile vs desktop (I'd guess that mobile 
   is smaller than desktop, but smaller enough to matter?), or collapse 
   languages in groups of, say 4-8 - do you add 20% to the total compiled 
   size, or 1%?
   - Do you always need separate permutations? For acceptance testing, you 
   likely want the same build that would go into a production release, but 
   maybe it is okay to add 15 minutes to those build times, but for "does this 
   PR build?" or "post-merge, does main still pass tests?", you might be able 
   to support a subset of values, or just a collapsed set, saving time, but 
   producing somewhat larger output.
   - Any other configuration you've experimented with? As you alluded to, 
   you can split the process up when building permutations via the 
   "gwt.jjs.permutationWorkerFactory" system property. In short, this is 
   customizable to not just decide "all work stays in-process" or "fork 
   another JVM per permutation (and tune memory usage carefully)", but also 
   how many workers come from each source. The default (see 
   PermutationWorkerFactory for specifics) is to run 
   both ThreadedPermutationWorkerFactory for the permutations, then 
   ExternalPermutationWorkerFactory for the next, etc. The -localWorkers 
   option and "gwt.jjs.maxThreads" system property will further control how 
   work is divided. 
   - Javadoc for ExternalPermutationWorkerFactory indicates that it runs 
   CompilePermsServer instances, but the isLocal method still returns true. A 
   custom worker factory can also be written to not just write work to disk 
   and handle it in a forked JVM, but even copy to another machine and 
   communicate with it remotely.

I _suspect_ you won't get too far into the weeds with this before finding a 
happy medium with small-enough compiled output and fast enough 
development/CI builds, but that at least covers where I would get started 
in considering this. Moving locales out of the compiled JS is definitely 
another option (and not too difficult to achieve, at least as long as you 
are focused on Constants rather than Messages), but it can be a bit harder 
to let the compiler be as aggressive about ensuing you keep unused output 
out of browsers.

On Wednesday, January 3, 2024 at 6:29:08 PM UTC-6 Alexander Bertram wrote:

Hi there,
We have been using GWT to build our product for a very long time. Recently, 
we've faced a new challenge as we've steadily been increasing the number of 
supported translations of the application to support a global audience. 
We're up to 24 languages, and could conceivably hit 40 in the coming year.

With all of these languages, come 

Re: Running GWT 2.4.0 using JDK 17

[Colin Alworth]

Aiming for next week - we hit a release blocker when getting ready to ship 
it for this week, and once https://github.com/gwtproject/gwt/pull/9888 
merges, we will start the release process and smoke testing again. That 
will take a few days, then we will add the github release and deploy to 
maven central, as well as update the website with release notes, etc.

You can always use nightly builds from the 
https://oss.sonatype.org/content/repositories/snapshots/ snapshot repo, 
with version HEAD-SNAPSHOT. If you're available to help us with an hour or 
so of smoke tests, we can always use more volunteers (contact me off-list). 

On Wednesday, January 3, 2024 at 2:36:34 PM UTC-6 Jim Douglas wrote:

> Apologies for the off-topic question, but is there an estimated timeframe 
> for GWT 2.11?
>
> On Wednesday, January 3, 2024 at 8:55:25 AM UTC-8 Colin Alworth wrote:
>
>> (I wrote a longer reply, but Google Groups ate it and never posted it, so 
>> apologies for brevity here):
>>
>> Without more information, it is hard to give a specific answer - are you 
>> just hoping to update the Java version and make no changes to the 
>> application? It might be that nothing at all needs to be done. If you're 
>> using GWT-RPC, you might have no changes to make at all, or you might need 
>> an --add-opens jvm arg for a few specific classes (fix to be released in 
>> GWT 2.11). 
>>
>> On the other hand, if you're running the compiler or dev mode on Java 17, 
>> other changes are likely needed, due to dependencies that have changed with 
>> the Java update.
>>
>> GWT 2.4.0 was released just over 12 years ago, and was intended to run on 
>> Java 6 - even Java 8 will only be ten years old in about two months.
>>
>> On Wednesday, January 3, 2024 at 8:40:28 AM UTC-6 anjana@gmail.com 
>> wrote:
>>
>>> Hi Team,
>>>
>>> Due to some business constraints our application is still running on old 
>>> GWT.2.4.0 and now we wanted to upgrade java version of our application to 
>>> JDK 17.  is it possible to run GWT.2.4.0 on an application which uses JDK 
>>> 17? if yes, can you please guide me with the helpful  resources for the 
>>> same?
>>>
>>> Thanks,
>>> Anjana
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/3880a3b8-3139-4055-b63e-d5dcea9e7c1en%40googlegroups.com.

Re: Running GWT 2.4.0 using JDK 17

[Colin Alworth]

(I wrote a longer reply, but Google Groups ate it and never posted it, so 
apologies for brevity here):

Without more information, it is hard to give a specific answer - are you 
just hoping to update the Java version and make no changes to the 
application? It might be that nothing at all needs to be done. If you're 
using GWT-RPC, you might have no changes to make at all, or you might need 
an --add-opens jvm arg for a few specific classes (fix to be released in 
GWT 2.11). 

On the other hand, if you're running the compiler or dev mode on Java 17, 
other changes are likely needed, due to dependencies that have changed with 
the Java update.

GWT 2.4.0 was released just over 12 years ago, and was intended to run on 
Java 6 - even Java 8 will only be ten years old in about two months.

On Wednesday, January 3, 2024 at 8:40:28 AM UTC-6 anjana@gmail.com 
wrote:

> Hi Team,
>
> Due to some business constraints our application is still running on old 
> GWT.2.4.0 and now we wanted to upgrade java version of our application to 
> JDK 17.  is it possible to run GWT.2.4.0 on an application which uses JDK 
> 17? if yes, can you please guide me with the helpful  resources for the 
> same?
>
> Thanks,
> Anjana
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/2caa6cc9-5306-42a2-9a11-b7091211cf45n%40googlegroups.com.

Re: Seeking Guidance: GWT Version with Resolved XSS Vulnerabilities - Which One to Use?

[Colin Alworth]

I think what Frank is saying is that those linked issues all related to the 
GWTTestCase tooling, which is only used for unit tests, and no 
reasonably-configured application will be serving GWTTestCase contents to 
users (and will usually only be available locally for 10s of seconds, on a 
randomly numbered http port). Regardless, this was fixed in the 2.5.1 
release. 

I don't understand what you mean that your attached references indicate 
that the issue persists - the first message notes that it was resolved in 
2.5.1-rc1 - have you confirmed that there is still an issue in some way?

The gwt mailing list email (your third link) enumerates a few 
plausible-looking issues identified through automated tooling, and explains 
why these are not real issues. At the time of writing, GWT 2.8.1 was the 
latest release, so at least 2.8.1 will resolve all of the mentioned issues.

It typically has been the policy of the GWT Project to not backport fixes, 
but maintain backwards compatibility whenever possible (even sometimes 
beyond what may seem reasonable, like continuing to support IE11 past its 
end-of-life date, etc). For this reason, we always advise to update to the 
latest GWT release, to ensure the best compatibility with other tools you 
are using - newer Java releases, browser updates, etc.

On Tuesday, December 26, 2023 at 7:47:27 AM UTC-6 flosanlop17 wrote:

> Hi Frank, I'm sorry, but I don't understand your answer, could you explain 
> a little better, thank you!
>
> On Friday, December 22, 2023 at 8:15:29 AM UTC-5 Frank Hossfeld wrote:
>
>> you should never deploy your tests into production.
>> flosanlop17 schrieb am Donnerstag, 21. Dezember 2023 um 17:52:49 UTC+1:
>>
>>> I am currently working on some security incidents reported in an 
>>> application that uses GWT, in its version 2.5.0 according to the report for 
>>> this version there are security vulnerabilities related to XSS, I was 
>>> reading a little the real notes of the versions above this one for example 
>>> 2.5.1 indicates that this vulnerability was fixed,  But on investigation it 
>>> seems that this is not the case, according to the attached references this 
>>> novelty still persists.
>>>
>>> Continue reading the actual notes of later versions, but it's not clear 
>>> if any security patches were worked on in new versions.
>>>
>>> Reading the forum, I notice that in version 2.8.1 a vulnerability 
>>> related to XSS was also identified again.
>>>
>>> My question is which version then I could use that currently has these 
>>> vulnerabilities fixed.
>>>
>>> Very thanks for your help.
>>>
>>> References
>>> https://www.openwall.com/lists/oss-security/2013/08/05/3
>>> https://www.openwall.com/lists/oss-security/2013/08/05/1
>>> https://groups.google.com/g/google-web-toolkit/c/Tx29wSZ8SZQ
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/7a2fe253-5cf5-4ee7-8cd6-ca552e973250n%40googlegroups.com.

Re: Migrating from 2.5.0 to 2.7.0

[Colin Alworth]

Its a bit hard to read the screenshots, but it looks like the file your 
browser/burp network log shows isn't one that even exists in your project? 
If those bytes were indeed sent over the wire and the old ...15.cache.html 
file was not present anywhere in your workspace or generated production 
code (date is 27 Dec, but last-modified is 21 Dec...), I would guess that 
either you have a proxy helping and incorrectly caching beyond what it 
should, or the server deployment somehow didn't replace all of the old 
files.
Also check what the contents of your .nocache.js file, as that is probably 
either stale or incorrectly cached by the browser/proxy/both. Note that 
this file should have changed dramatically - your old ...15.cache.html file 
ends in ".html", but all of the new files are .cache.js instead, so you've 
switched linkers as well during your upgrade.

Finally please note that GWT 2.7.0 is a little over 9 years old, so it 
might make sense to keep updating, and see if you can get to GWT 2.10 (and 
the 2.11 release process is starting soon).

On Wednesday, December 27, 2023 at 4:38:00 PM UTC-6 flosanlop17 wrote:

> I am currently migrating an application that uses GWT version 2.5.0, I am 
> trying to migrate it, I have already updated some libraries that conflicted 
> with this new version and I have solved some problems.
>
> Currently the compilation is successful, and I manage to deploy to my 
> local Oracle Weblogic Server, but when I analyze the HTTP requests with 
> BurpSuite, I see that apparently they are loading cache files that point to 
> version 2.5.0, someone could explain me why this happens and how I could 
> solve it...
>
> I share the cache files in my local seem to be updated, and indeed the 
> compilation is generated on version 2.7.0 as seen in the following images
>
> [image: Screenshot_12.png]
>
> [image: Screenshot_13.png]
>
> But when the first requests are made to enter the application it is 
> observed that it loads a cache file that points to version 2.5.0, as shown 
> in the image below.
>
> [image: Screenshot_14.png]
>
> Thank you very much for your help
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/3aca1d9f-f9b3-4747-a255-4b7293f654ban%40googlegroups.com.

Re: Migration from 2.7.0 to 2.9.0

[Colin Alworth]

Can you share the complete build log? At a guess, there is some classpath 
mismatch, mixing parts of GWT 2.7 with 2.9 - the Core module is always 
included as an inherits for every module, even if that module is empty, so 
this suggests an earlier error that prevented that module from working, or 
prevented the compiler from finding it.

On Tuesday, December 19, 2023 at 8:51:25 PM UTC-6 kua...@gmail.com wrote:

> Hello GWT Users,
>
> I'm trying to migrate very old project from GWT 2.7.0 to GWT 2.9.0
>
> Project build with Gradle.
>
> Everything is working as expected for GWT 2.7.0, but when I update to GWT 
> 2.9.0
> build failed with message "[ERROR] Hint: Check that your module inherits 
> 'com.google.gwt.core.Core' either directly or indirectly (most often) by 
> inheriting module `com.google.gwt.user.User`"
>
> I've simply changed version in "build.gradle".
> Java compilation succeeded and even window with Dev mode launcher appeared 
> on the screen.
>
> I think it is some misconfiguration. Maybe something changed in GWT 2.9.0 
> configuration?
>
> Any ideas what am I missing?
>
> Alexey Kuznetsov
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/77311ac7-5fbd-40c5-abe3-8404dc89d4d3n%40googlegroups.com.

Re: How to debug the java code on the eclipse ide with the tbroyer gwt maven plugin ?

[Colin Alworth]

That's great news! Related, I had understood that this didn't work at all, 
but I discovered via 
https://bugs.chromium.org/p/chromium/issues/detail?id=327092 that there is 
an "experimental" feature in chrome that lets locals be displayed.
[image: screenshot867.png]
However even with this enabled, only locals/params will show up with their 
correct names - any fields on those, or fields on "this" will still require 
finding their obfuscated names.

On Tuesday, December 12, 2023 at 9:47:40 AM UTC-6 Thomas Broyer wrote:

> On Tuesday, December 12, 2023 at 3:44:34 PM UTC+1 gardella...@gmail.com 
> wrote:
>
> Which limitation are you referring to? Is it something that can be fixed 
> or is it impossible to fix variable names there?
>
>
>
> https://ecma-international.org/news/ecma-tc39-ecmascript-initiates-a-new-task-group-to-standardize-source-maps/
> > The group’s plan is to identify the gaps, bring completeness and clarity 
> to the current specification; and help source map debuggers, generators and 
> tools to adhere to the updated specification. The intent is to work 
> together on *adding long requested features such as passing through 
> function and variable names*, and debug IDs to quickly identify source 
> files or scope information. 
>
> (emphasis mine)
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/a876be26-063e-4466-a5c5-5f5760293733n%40googlegroups.com.

Re: How to debug the java code on the eclipse ide with the tbroyer gwt maven plugin ?

[Colin Alworth]

The gwt-eclipse-plugin is maintained, but browsers removed the API that was 
previously used to let a Java debugger connect to a running GWT 
application. This API was used by a browser plugin that was shipped as part 
of GWT. Technically GWT still supports this, but I believe only IE11 (and 
htmlunit) can actually use it, and its use is discouraged, some other GWT 
features will not work with it.

There is a separate plugin, https://sdbg.github.io/ that is also 
maintained, that allows eclipse to debug GWT apps via sourcemaps, much the 
same as the browser's own debugger will do.

The issues you're observing with variable renaming making it difficult to 
inspect values is caused by limitations in JS sourcemaps themselves.

On Tuesday, December 12, 2023 at 12:26:16 AM UTC-6 ralph.f...@gmail.com 
wrote:

> Yes, unfortunately the Eclipse plug-in is no longer maintained. Debugging 
> in the browser is the way to go! It works the same as for other JavaScript 
> frameworks (e.g. Angular) using a standard feature to map generated 
> JavaScript onto the source code (be it Java or Typescript etc.). That is, 
> you can set breakpoints and inspect the runtime values of your variables. 
> There is just one issue with variable names which differ between Java and 
> JavaScript but this is mostly cosmetic.
>
> Marco Tenti (IoProgrammo88)  schrieb am Mo. 11. Dez. 
> 2023 um 13:31:
>
>> So this debug mode is deprecated  
>> https://www.gwtproject.org/doc/latest/tutorial/debug.html  ? 
>>
>> When I launch the "gwt:codeServer" command, i  go to the sources panel of 
>> the browser chrome, and I can browse the code and set the breakpoints , but 
>> I can not "see" the runtime values of the variables as it happens with 
>> standard javascript is this correct ?
>>
>>  [image: ErrorPskCallStack.png]
>>
>> Il giorno lunedì 4 dicembre 2023 alle 13:30:37 UTC+1 Ralph Fiergolla ha 
>> scritto:
>>
>>> If I am not mistaken, you are mixing up things a little: the issue you 
>>> were looking at here 
>>> https://github.com/tbroyer/gwt-maven-plugin/issues/82 is not about 
>>> debugging the generated client part of your application, but about the 
>>> compiler that is actually generating the code you want to debug. 
>>>
>>> To avoid wasting your time trying to set up the Eclipse Plugin I would 
>>> suggest using your browser's built-in development tools (Ctrl+Shift+I). You 
>>> will see your JAVA source code and can put your breakpoints etc. and step 
>>> through your code. This works in Chrome, Firefox, Edge.
>>>
>>> Bon courage
>>> Ralph
>>>
>>> On Mon, Dec 4, 2023 at 1:16 PM Marco Tenti (IoProgrammo88) <
>>> tenti...@gmail.com> wrote:
>>>
 Hello everyone, I am updating some old gwt projects and I started to 
 study about 15 days ago the gwt framework, this is to specify that I don't 
 know all the secrets of the framework yet.

 Following Nalu's approach and starting from his example at 
 https://github.com/NaluKit/nalu-examples/tree/main/nalu-simple-app-example,
  
 I was able to start with the gwt:codeserver both client and server part of 
 my projects successfully.

 Unfortunately, I still haven't figured out what I need to do to 
 enablethe  debugging on the client part of the project on the IDE eclipse.

 I've read in this issue 
 https://github.com/tbroyer/gwt-maven-plugin/issues/82 a possible 
 solution, but it doesn't seem to work, I'm 100% sure I'm doing something 
 wrong myself., can anyone tell me looking at Nalu's example what 
 additional 
 commands I need to set to configure to debugging on the client java code 
 in 
 the eclipse ide ?

 -- 
 You received this message because you are subscribed to the Google 
 Groups "GWT Users" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to google-web-tool...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/google-web-toolkit/3369c8a1-d86f-40de-9816-d35d865a1e4en%40googlegroups.com
  
 
 .

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "GWT Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-web-tool...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit/ed37a5ea-c5fa-4a74-9c37-3839311f410en%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [gwt-contrib] Re: Preparing for GWT 2.11 release

[Colin Alworth]

We're still in the "please help us review the last few merges" phase 
(especially looking for notes on deprecating using DevMode as an app 
server, and comments on if tests added for other PRs seem sufficient), then 
we'll make some release artifacts (late next week is my guess). I'm hoping 
to merge most of the open PRs, so we want to not start testing until we've 
landed that changes that will make this release.

That being said, we ship HEAD-SNAPSHOT every night off of main, you can add 
https://oss.sonatype.org/content/repositories/snapshots/ as a snapshot 
repository to your project to use that build (be certain you are using 
org.gwtproject groupids). If you need nightly download zips, they are 
available at 
https://github.com/gwtproject/gwt/actions/workflows/full-check.yml, click 
any build, scroll down artifacts, and download gwt-java17.zip. While this 
was built with Java 17, it is compatible with Java 8+ and will be used for 
the release. The other builds should be nearly identical - the main change 
should be in the javadoc output. The build produced from Java8 is 
substantially smaller since it doesn't include javadoc at all, since the 
APIs we now use are not compatible there.

On Thursday, November 23, 2023 at 7:36:55 AM UTC-6 Juan Pablo Gardella 
wrote:

> Hello, is gwt-2.11 artifacts available somewhere for testing against the 
> applications I am currently working on?
>
> On Tue, Nov 14, 2023, 11:37 PM Colin Alworth  wrote:
>
>> It has taken longer than we had hoped, but I think we're just about ready 
>> - GWT itself can build on Java 17 (and can run on Java 23), JRE emulation 
>> is nearly caught up to where we wanted with Java 11, and jakarta.servlet 
>> support is hopefully finished and partially tested in non-trivial apps.
>>
>> Here's my view of what might land before we cut a release:
>>
>>- The jakarta.servlet patch is now at 
>>https://github.com/gwtproject/gwt/pull/9845, and is effectively ready 
>>to land. To my knowledge, no jakarta project has tested the 
>>requestfactory-*.jars yet.
>>- As above, we need confirmation that 
>>https://github.com/gwtproject/gwt/pull/9785 solves the problem it was 
>>created for.
>>- As above https://github.com/gwtproject/gwt/pull/9799 (fixing some 
>>ternary expressions and other type unions) should get at least one more 
>>review, approval. This will be applicable for Java 17 language support.
>>- Two more JRE emulation patches: 
>>https://github.com/gwtproject/gwt/pull/9860 needs a review, and 
>>https://github.com/gwtproject/gwt/pull/9862 needs follow-up and 
>>another review.
>>
>> If this is the last release that can run the compiler and dev mode on 
>> Java 8, we will want to update Jetty in the next release as well. That 
>> might suggest one more change, deprecating the use of "-server" in DevMode. 
>> Please see https://github.com/gwtproject/gwt/issues/9863 for more 
>> details. In the coming days I'll put together a patch for this.
>>
>> After we've merged or deferred these PRs, the next step will be asking 
>> for testing volunteers and cutting an RC release. I'm hoping we can begin 
>> that process within two weeks - if you're interested in helping us test 
>> this release, please reply to this message or directly with the 
>> OS/JVM/Browsers you have at your disposal, and I'll make sure you are 
>> included. As usual, the testing process will probably take a week or so to 
>> get the desired coverage, and then we'll formally release GWT 2.11.0.
>>
>> On Tuesday, May 23, 2023 at 3:11:51 PM UTC-5 Rocco De Angelis wrote:
>>
>>> Hi Colin,
>>>
>>> if you need some help, I'm feeling to help. 
>>> Specially the jakarta stuff is important for us.
>>> Do you find the time to have a look to the open PR?
>>>
>>> BR
>>> Rocco
>>>
>>> Colin Alworth schrieb am Mittwoch, 17. Mai 2023 um 16:44:58 UTC+2:
>>>
>>>> There have been a few suggestions of making a release in the near 
>>>> future, and it seemed like it might be a good idea to summarize pending 
>>>> development, ask for help to land these, and see if anything else needs to 
>>>> be addressed before shipping.
>>>>
>>>>
>>>>- There is a pending branch (not yet a PR for GWT itself) working 
>>>>on adding a new gwt-servlet-jakarta.jar and 
>>>>requestfactory-server-jakarta.jar as part of 
>>>>https://github.com/gwtproject/gwt/issues/9727. There is no plan at 
>>>>this time to update the DevMode server to Jakarta, though that w

Re: Code fails to compile with GWT 2.10.0

[Colin Alworth]

Reviewing https://github.com/GwtMaterialDesign/gwt-material/releases, I see 
that 2.4.0 was the first version that was built against GWT 2.9 itself, and 
latest HEAD still appears to use GWT 2.9.0 according to the pom file. 

On the other hand, at 
https://github.com/GwtMaterialDesign/gwt-material-jquery/releases (which is 
where the gwt.material.design.jquery.JQuery module in your error message 
comes from), it appears that gwt-material.jquery 2.6.0 removed IE10, so 
should be compatible with GWT 2.10.0. In turn, 
https://github.com/GwtMaterialDesign/gwt-material/blob/f00988f392ef0e8f4c839dce8cf1fbb05dc10ae6/gwt-material/pom.xml#L21
 
shows that the gwt-material matches the same version of 
gwt-material-jquery, so I would expect that gmd 2.6.0+ will work for you 
(latest is 2.8.3).

Their Javadoc is linked from their readme, see 
https://gwtmaterialdesign.github.io/gwt-material-demo/apidocs/. I don't 
obviously see AsyncButton in there (might be in one of the other repos like 
addins?) but I also don't use GMD on a regular basis. 

You might also find more luck in their gitter chat 
(https://matrix.to/#/#GwtMaterialDesign_gwt-material:gitter.im), slack 
channel (https://gmd-project.slack.com/), or issue tracker.

On Tuesday, November 21, 2023 at 4:09:39 PM UTC-6 kool...@gmail.com wrote:

> Attempting move an application that has been working good with GWT 2.9 to 
> 2.10.0. However, the compile task is running into the following issue:
>
> Listening for transport dt_socket at address: 4
>  Loading inherited module 'com.peruselab.peruse.Peruse'
> Loading inherited module 'gwt.material.design.GwtMaterialWithJQuery'
>Loading inherited module 'gwt.material.design.GwtMaterialDesignBase'
>   Loading inherited module 'gwt.material.design.jquery.JQuery'
>  Loading inherited module 'gwt.material.design.jscore.JSCore'
> [ERROR] Line 26: Value 'ie10' in not a valid value for 
> property 'user.agent'
>
> Seeing the issue's originating from GMD, I thought I should move that too 
> from 2.1 to a higher version. Moved to 2.2 but the AsyncButton is moved 
> from gwt.material.design.incubator.client.async to somewhere else. Tried 
> looking for the release notes but I couldn't put my hands on that either.
>
> Any idea if AsyncButton is still available or replaced by something else? 
> Or, is there a pointer to the JavaDoc please?
>
> I appreciate your help.
>
> Thanks
> Velu
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/cdb3fca8-ea89-4db0-9c15-d436e2fed6a5n%40googlegroups.com.

[gwt-contrib] Re: Preparing for GWT 2.11 release

[Colin Alworth]

Yes, I'll create a staging repository with the actual artifacts that we 
intend to release to Maven Central, and will also provide a .zip download 
for the SDK itself.

On Wednesday, November 15, 2023 at 8:16:40 AM UTC-6 Zbyněk Konečný wrote:

> Hi,
>
> I can do some testing on Windows with Java 11 and Chrome/Edge/Firefox. 
> Will the jars for testing be available in some Maven repo?
>
> Cheers,
> Zbynek
>
> On Wednesday, November 15, 2023 at 3:37:38 AM UTC+1 Colin Alworth wrote:
>
>> It has taken longer than we had hoped, but I think we're just about ready 
>> - GWT itself can build on Java 17 (and can run on Java 23), JRE emulation 
>> is nearly caught up to where we wanted with Java 11, and jakarta.servlet 
>> support is hopefully finished and partially tested in non-trivial apps.
>>
>> Here's my view of what might land before we cut a release:
>>
>>- The jakarta.servlet patch is now at 
>>https://github.com/gwtproject/gwt/pull/9845, and is effectively ready 
>>to land. To my knowledge, no jakarta project has tested the 
>>requestfactory-*.jars yet.
>>- As above, we need confirmation that 
>>https://github.com/gwtproject/gwt/pull/9785 solves the problem it was 
>>created for.
>>- As above https://github.com/gwtproject/gwt/pull/9799 (fixing some 
>>ternary expressions and other type unions) should get at least one more 
>>review, approval. This will be applicable for Java 17 language support.
>>- Two more JRE emulation patches: 
>>https://github.com/gwtproject/gwt/pull/9860 needs a review, and 
>>https://github.com/gwtproject/gwt/pull/9862 needs follow-up and 
>>another review.
>>
>> If this is the last release that can run the compiler and dev mode on 
>> Java 8, we will want to update Jetty in the next release as well. That 
>> might suggest one more change, deprecating the use of "-server" in DevMode. 
>> Please see https://github.com/gwtproject/gwt/issues/9863 for more 
>> details. In the coming days I'll put together a patch for this.
>>
>> After we've merged or deferred these PRs, the next step will be asking 
>> for testing volunteers and cutting an RC release. I'm hoping we can begin 
>> that process within two weeks - if you're interested in helping us test 
>> this release, please reply to this message or directly with the 
>> OS/JVM/Browsers you have at your disposal, and I'll make sure you are 
>> included. As usual, the testing process will probably take a week or so to 
>> get the desired coverage, and then we'll formally release GWT 2.11.0.
>>
>> On Tuesday, May 23, 2023 at 3:11:51 PM UTC-5 Rocco De Angelis wrote:
>>
>>> Hi Colin,
>>>
>>> if you need some help, I'm feeling to help. 
>>> Specially the jakarta stuff is important for us.
>>> Do you find the time to have a look to the open PR?
>>>
>>> BR
>>> Rocco
>>>
>>> Colin Alworth schrieb am Mittwoch, 17. Mai 2023 um 16:44:58 UTC+2:
>>>
>>>> There have been a few suggestions of making a release in the near 
>>>> future, and it seemed like it might be a good idea to summarize pending 
>>>> development, ask for help to land these, and see if anything else needs to 
>>>> be addressed before shipping.
>>>>
>>>>
>>>>- There is a pending branch (not yet a PR for GWT itself) working 
>>>>on adding a new gwt-servlet-jakarta.jar and 
>>>>requestfactory-server-jakarta.jar as part of 
>>>>https://github.com/gwtproject/gwt/issues/9727. There is no plan at 
>>>>this time to update the DevMode server to Jakarta, though that will 
>>>>eventually be inevitable if we move to a newer version of Jetty. Work 
>>>> on 
>>>>this can be found at https://github.com/niloc132/gwt/pull/3.
>>>>- There is a pending fix for eliminating a false positive from 
>>>>using some internals of protobuf to deobfuscate client side exceptions 
>>>>https://github.com/gwtproject/gwt/pull/9785. This is probably safe 
>>>>to land without more testing, but none of the reporters of this bug 
>>>> have 
>>>>verified the fix.
>>>>- There's a pending fix for a bug in type unions, which can be 
>>>>caused by some ternary expressions and var type declarations 
>>>>https://github.com/gwtproject/gwt/pull/9799. A review found a few 
>>>>oversights in testing, and I'd appreciate another look.
>>>>- The

[gwt-contrib] Re: Preparing for GWT 2.11 release

[Colin Alworth]

It has taken longer than we had hoped, but I think we're just about ready - 
GWT itself can build on Java 17 (and can run on Java 23), JRE emulation is 
nearly caught up to where we wanted with Java 11, and jakarta.servlet 
support is hopefully finished and partially tested in non-trivial apps.

Here's my view of what might land before we cut a release:

   - The jakarta.servlet patch is now at 
   https://github.com/gwtproject/gwt/pull/9845, and is effectively ready to 
   land. To my knowledge, no jakarta project has tested the 
   requestfactory-*.jars yet.
   - As above, we need confirmation that 
   https://github.com/gwtproject/gwt/pull/9785 solves the problem it was 
   created for.
   - As above https://github.com/gwtproject/gwt/pull/9799 (fixing some 
   ternary expressions and other type unions) should get at least one more 
   review, approval. This will be applicable for Java 17 language support.
   - Two more JRE emulation patches: 
   https://github.com/gwtproject/gwt/pull/9860 needs a review, and 
   https://github.com/gwtproject/gwt/pull/9862 needs follow-up and another 
   review.
   
If this is the last release that can run the compiler and dev mode on Java 
8, we will want to update Jetty in the next release as well. That might 
suggest one more change, deprecating the use of "-server" in DevMode. 
Please see https://github.com/gwtproject/gwt/issues/9863 for more details. 
In the coming days I'll put together a patch for this.

After we've merged or deferred these PRs, the next step will be asking for 
testing volunteers and cutting an RC release. I'm hoping we can begin that 
process within two weeks - if you're interested in helping us test this 
release, please reply to this message or directly with the OS/JVM/Browsers 
you have at your disposal, and I'll make sure you are included. As usual, 
the testing process will probably take a week or so to get the desired 
coverage, and then we'll formally release GWT 2.11.0.

On Tuesday, May 23, 2023 at 3:11:51 PM UTC-5 Rocco De Angelis wrote:

> Hi Colin,
>
> if you need some help, I'm feeling to help. 
> Specially the jakarta stuff is important for us.
> Do you find the time to have a look to the open PR?
>
> BR
> Rocco
>
> Colin Alworth schrieb am Mittwoch, 17. Mai 2023 um 16:44:58 UTC+2:
>
>> There have been a few suggestions of making a release in the near future, 
>> and it seemed like it might be a good idea to summarize pending 
>> development, ask for help to land these, and see if anything else needs to 
>> be addressed before shipping.
>>
>>
>>- There is a pending branch (not yet a PR for GWT itself) working on 
>>adding a new gwt-servlet-jakarta.jar and 
>> requestfactory-server-jakarta.jar 
>>as part of https://github.com/gwtproject/gwt/issues/9727. There is no 
>>plan at this time to update the DevMode server to Jakarta, though that 
>> will 
>>eventually be inevitable if we move to a newer version of Jetty. Work on 
>>this can be found at https://github.com/niloc132/gwt/pull/3.
>>- There is a pending fix for eliminating a false positive from using 
>>some internals of protobuf to deobfuscate client side exceptions 
>>https://github.com/gwtproject/gwt/pull/9785. This is probably safe to 
>>land without more testing, but none of the reporters of this bug have 
>>verified the fix.
>>- There's a pending fix for a bug in type unions, which can be caused 
>>by some ternary expressions and var type declarations 
>>https://github.com/gwtproject/gwt/pull/9799. A review found a few 
>>oversights in testing, and I'd appreciate another look.
>>- There's a pending fix for a bug where debugging in firefox when 
>>assertions are enabled (for example in SDM). It turns out the bug can 
>>happen in other cases too in more subtle ways. A draft fix it at 
>>https://github.com/gwtproject/gwt/pull/9800.
>>- GWT itself can now be built on Java 11, but not yet 17. There are a 
>>few changes pending that will permit this. Additionally, this will enable 
>>adding more Java 9-11 JRE emulation, see the list at 
>>https://github.com/gwtproject/gwt/issues/9547.
>>
>>
>> Finally, we have an open question about future Java 8 support. Beyond 
>> this release, we likely will no longer support running the compiler in Java 
>> 8, which will enable adding support for Java 12-17 language features. We 
>> can likely still build jars that will run on a Java 8 server, but just 
>> can't compile newer JS. To that end, this 2.11 release branch may be 
>> longer-lived than usual, depending on feedback and support to continue 
>> bugfix releases after 2.12 eventually ships.
>>
>> Are there

Re: GWT New Project doesn't start because of Jetty problems.

[Colin Alworth]

Sorry, hit send too early - when using CodeServer, you should be sure to 
start your own tomcat - for whatever reason, that error message at 
localhost:8080 indicates that tomcat isn't running or isnt reachable at 
that port. 

On Monday, October 30, 2023 at 11:49:43 AM UTC-5 Colin Alworth wrote:

> At a glance, it appears that you started CodeServer rather than DevMode - 
> but the default port would have been  rather than 8080 if your app was 
> hosted by DevMode. 
>
> On Monday, October 30, 2023 at 11:42:04 AM UTC-5 lelo...@gmail.com wrote:
>
>> Hello thanks for the response. I did change to gwt 2.10 and I'm using the 
>> Tomcat as the  servlet container like you said. I manage to do this steps 
>> http://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/debugging/GWTDevModeAndTomcatWebServer.html
>>  
>> I everything is fine until I go to the explorer and this page comes first. 
>>
>> [image: 9876.png]
>>
>> I change the port and add the /AutoSys1-server/ like the tutorial said 
>> but this happens. 
>>
>> [image: 8080.png]
>>
>>
>> This are some info to give more context: 
>>
>> [image: debug-pro.png]
>> [image: debug.png]
>>
>> [image: log.png]
>>
>> [image: log2.png]
>>
>> On Sunday, October 29, 2023 at 3:37:49 PM UTC-4 Colin Alworth wrote:
>>
>>> There are a few options I would suggest:
>>>  * Upgrade to GWT 2.10 (especially since this is a new project). This is 
>>> probably the simplest and best option. The new version of Jetty used there 
>>> will not have this issue with scanning module files.
>>>  * Stop using DevMode as an application server - run your own server, 
>>> using the servlet container of your choice, and either pass -noserver to 
>>> DevMode, or switch to CodeServer. This is a good idea whether or not you 
>>> upgrade to GWT 2.10.
>>>  * Downgrade to Java8, or at least remove any dependency that uses 
>>> Java9+ bytecode. This might be your own project, based on the error 
>>> messages. This is probably a pretty terrible option, but if your brand new 
>>> project can't use latest GWT, and it happens that you don't actually need 
>>> that dependency and it solves the problem, then it might be acceptable. If 
>>> you actually want the annotation configuration to take place, take one/both 
>>> of the earlier options.
>>>  * Finally, it is possible to extend JettyLauncher and further customize 
>>> the types that Jetty will scan. Start by overriding createWebAppContext(), 
>>> configure the instance created by the super call as desired, then pass 
>>> -server com.mycompany.myserver.MyCustomJettyLauncher to dev mode when it 
>>> starts to use this type instead of the built in type.
>>>
>>> On Saturday, October 28, 2023 at 1:03:16 PM UTC-5 lelo...@gmail.com 
>>> wrote:
>>>
>>>> Hello. I'm trying to create a new GWT Project in Eclipse following the 
>>>> official tutorial. I'm using GWT 2.9 + JDK 11. I create the project with 
>>>> the plug in in eclipse but I can't debug the app like the tutorial said. 
>>>>
>>>> Loading Java files in com.ve.siaconca.AutoSys.
>>>>
>>>> Module setup completed in 5740 ms
>>>>
>>>> 2023-10-28 13:34:15.138:INFO:oejs.Server:main: jetty-9.2.z-SNAPSHOT
>>>>
>>>> 2023-10-28 13:34:15.212:INFO:oejsh.ContextHandler:main: Started 
>>>> o.e.j.s.ServletContextHandler@1eb918ed{/,null,AVAILABLE}
>>>>
>>>> 2023-10-28 13:34:15.268:INFO:oejs.ServerConnector:main: Started 
>>>> ServerConnector@37c5c9b9{HTTP/1.1}{127.0.0.1:9876}
>>>>
>>>> 2023-10-28 13:34:15.269:INFO:oejs.Server:main: Started @8336ms
>>>>
>>>>
>>>> The code server is ready at http://127.0.0.1:9876/
>>>>
>>>> Code server started in 6.471 s ms
>>>>
>>>> [ERROR] jreLeakPrevention.gcDaemonFail
>>>>
>>>> java.lang.ClassNotFoundException: sun.misc.GC
>>>>
>>>> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(
>>>> BuiltinClassLoader.java:581)
>>>>
>>>> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(
>>>> ClassLoaders.java:178)
>>>>
>>>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>>>
>>>> at java.base/java.lang.Class.forName0(Native Method)
>>>>
>>>> at java.base/java.lang.Class.forName(Class.java:315)
>

Re: GWT New Project doesn't start because of Jetty problems.

[Colin Alworth]

At a glance, it appears that you started CodeServer rather than DevMode - 
but the default port would have been  rather than 8080 if your app was 
hosted by DevMode. 

On Monday, October 30, 2023 at 11:42:04 AM UTC-5 lelo...@gmail.com wrote:

> Hello thanks for the response. I did change to gwt 2.10 and I'm using the 
> Tomcat as the  servlet container like you said. I manage to do this steps 
> http://gwt-plugins.github.io/documentation/gwt-eclipse-plugin/debugging/GWTDevModeAndTomcatWebServer.html
>  
> I everything is fine until I go to the explorer and this page comes first. 
>
> [image: 9876.png]
>
> I change the port and add the /AutoSys1-server/ like the tutorial said but 
> this happens. 
>
> [image: 8080.png]
>
>
> This are some info to give more context: 
>
> [image: debug-pro.png]
> [image: debug.png]
>
> [image: log.png]
>
> [image: log2.png]
>
> On Sunday, October 29, 2023 at 3:37:49 PM UTC-4 Colin Alworth wrote:
>
>> There are a few options I would suggest:
>>  * Upgrade to GWT 2.10 (especially since this is a new project). This is 
>> probably the simplest and best option. The new version of Jetty used there 
>> will not have this issue with scanning module files.
>>  * Stop using DevMode as an application server - run your own server, 
>> using the servlet container of your choice, and either pass -noserver to 
>> DevMode, or switch to CodeServer. This is a good idea whether or not you 
>> upgrade to GWT 2.10.
>>  * Downgrade to Java8, or at least remove any dependency that uses Java9+ 
>> bytecode. This might be your own project, based on the error messages. This 
>> is probably a pretty terrible option, but if your brand new project can't 
>> use latest GWT, and it happens that you don't actually need that dependency 
>> and it solves the problem, then it might be acceptable. If you actually 
>> want the annotation configuration to take place, take one/both of the 
>> earlier options.
>>  * Finally, it is possible to extend JettyLauncher and further customize 
>> the types that Jetty will scan. Start by overriding createWebAppContext(), 
>> configure the instance created by the super call as desired, then pass 
>> -server com.mycompany.myserver.MyCustomJettyLauncher to dev mode when it 
>> starts to use this type instead of the built in type.
>>
>> On Saturday, October 28, 2023 at 1:03:16 PM UTC-5 lelo...@gmail.com 
>> wrote:
>>
>>> Hello. I'm trying to create a new GWT Project in Eclipse following the 
>>> official tutorial. I'm using GWT 2.9 + JDK 11. I create the project with 
>>> the plug in in eclipse but I can't debug the app like the tutorial said. 
>>>
>>> Loading Java files in com.ve.siaconca.AutoSys.
>>>
>>> Module setup completed in 5740 ms
>>>
>>> 2023-10-28 13:34:15.138:INFO:oejs.Server:main: jetty-9.2.z-SNAPSHOT
>>>
>>> 2023-10-28 13:34:15.212:INFO:oejsh.ContextHandler:main: Started 
>>> o.e.j.s.ServletContextHandler@1eb918ed{/,null,AVAILABLE}
>>>
>>> 2023-10-28 13:34:15.268:INFO:oejs.ServerConnector:main: Started 
>>> ServerConnector@37c5c9b9{HTTP/1.1}{127.0.0.1:9876}
>>>
>>> 2023-10-28 13:34:15.269:INFO:oejs.Server:main: Started @8336ms
>>>
>>>
>>> The code server is ready at http://127.0.0.1:9876/
>>>
>>> Code server started in 6.471 s ms
>>>
>>> [ERROR] jreLeakPrevention.gcDaemonFail
>>>
>>> java.lang.ClassNotFoundException: sun.misc.GC
>>>
>>> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(
>>> BuiltinClassLoader.java:581)
>>>
>>> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(
>>> ClassLoaders.java:178)
>>>
>>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>>
>>> at java.base/java.lang.Class.forName0(Native Method)
>>>
>>> at java.base/java.lang.Class.forName(Class.java:315)
>>>
>>> at com.google.gwt.dev.shell.jetty.JettyLauncher.jreLeakPrevention(
>>> JettyLauncher.java:899)
>>>
>>> at com.google.gwt.dev.shell.jetty.JettyLauncher.start(
>>> JettyLauncher.java:722)
>>>
>>> at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:636)
>>>
>>> at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:898)
>>>
>>> at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:705)
>>>
>>> at com.google.gwt.dev.DevMode.main(DevMode.java:432)
>>>
>>> 2023-10-28 13:34:15.591:INFO:oejs.Server:main: jetty-

Re: GWT New Project doesn't start because of Jetty problems.

[Colin Alworth]

There are a few options I would suggest:
 * Upgrade to GWT 2.10 (especially since this is a new project). This is 
probably the simplest and best option. The new version of Jetty used there 
will not have this issue with scanning module files.
 * Stop using DevMode as an application server - run your own server, using 
the servlet container of your choice, and either pass -noserver to DevMode, 
or switch to CodeServer. This is a good idea whether or not you upgrade to 
GWT 2.10.
 * Downgrade to Java8, or at least remove any dependency that uses Java9+ 
bytecode. This might be your own project, based on the error messages. This 
is probably a pretty terrible option, but if your brand new project can't 
use latest GWT, and it happens that you don't actually need that dependency 
and it solves the problem, then it might be acceptable. If you actually 
want the annotation configuration to take place, take one/both of the 
earlier options.
 * Finally, it is possible to extend JettyLauncher and further customize 
the types that Jetty will scan. Start by overriding createWebAppContext(), 
configure the instance created by the super call as desired, then pass 
-server com.mycompany.myserver.MyCustomJettyLauncher to dev mode when it 
starts to use this type instead of the built in type.

On Saturday, October 28, 2023 at 1:03:16 PM UTC-5 lelo...@gmail.com wrote:

> Hello. I'm trying to create a new GWT Project in Eclipse following the 
> official tutorial. I'm using GWT 2.9 + JDK 11. I create the project with 
> the plug in in eclipse but I can't debug the app like the tutorial said. 
>
> Loading Java files in com.ve.siaconca.AutoSys.
>
> Module setup completed in 5740 ms
>
> 2023-10-28 13:34:15.138:INFO:oejs.Server:main: jetty-9.2.z-SNAPSHOT
>
> 2023-10-28 13:34:15.212:INFO:oejsh.ContextHandler:main: Started 
> o.e.j.s.ServletContextHandler@1eb918ed{/,null,AVAILABLE}
>
> 2023-10-28 13:34:15.268:INFO:oejs.ServerConnector:main: Started 
> ServerConnector@37c5c9b9{HTTP/1.1}{127.0.0.1:9876}
>
> 2023-10-28 13:34:15.269:INFO:oejs.Server:main: Started @8336ms
>
>
> The code server is ready at http://127.0.0.1:9876/
>
> Code server started in 6.471 s ms
>
> [ERROR] jreLeakPrevention.gcDaemonFail
>
> java.lang.ClassNotFoundException: sun.misc.GC
>
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(
> BuiltinClassLoader.java:581)
>
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(
> ClassLoaders.java:178)
>
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>
> at java.base/java.lang.Class.forName0(Native Method)
>
> at java.base/java.lang.Class.forName(Class.java:315)
>
> at com.google.gwt.dev.shell.jetty.JettyLauncher.jreLeakPrevention(
> JettyLauncher.java:899)
>
> at com.google.gwt.dev.shell.jetty.JettyLauncher.start(
> JettyLauncher.java:722)
>
> at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:636)
>
> at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:898)
>
> at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:705)
>
> at com.google.gwt.dev.DevMode.main(DevMode.java:432)
>
> 2023-10-28 13:34:15.591:INFO:oejs.Server:main: jetty-9.2.z-SNAPSHOT
>
> Starting Jetty on port 
>
> 2023-10-28 13:34:18.199:INFO:oejs.ServerConnector:main: Started 
> ServerConnector@677e3282{HTTP/1.1}{127.0.0.1:}
>
> 2023-10-28 13:34:18.202:INFO:oejs.Server:main: Started @11268ms
>
> [WARN] Failed startup of context 
> c.g.g.d.s.j.WebAppContextWithReload@6cc8136b{/,file:/C:/Users/VICTOR/eclipse-workspace/AutoSys/war/,STARTING}{C:\Users\VICTOR\eclipse-workspace\AutoSys\war}
>
> MultiException[java.lang.RuntimeException: Error scanning file 
> AutoSys$1.class, java.lang.RuntimeException: Error scanning file 
> AutoSys$1MyHandler$1.class, java.lang.RuntimeException: Error scanning 
> file AutoSys$1MyHandler.class, java.lang.RuntimeException: Error scanning 
> file AutoSys.class]
>
> at 
> org.eclipse.jetty.annotations.AnnotationConfiguration.scanForAnnotations(
> AnnotationConfiguration.java:536)
>
> at org.eclipse.jetty.annotations.AnnotationConfiguration.configure(
> AnnotationConfiguration.java:447)
>
> at org.eclipse.jetty.webapp.WebAppContext.configure(WebAppContext.java:479
> )
>
> at org.eclipse.jetty.webapp.WebAppContext.startContext(
> WebAppContext.java:1337)
>
> at org.eclipse.jetty.server.handler.ContextHandler.doStart(
> ContextHandler.java:741)
>
> at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
>
> at 
> com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(
> JettyLauncher.java:550)
>
> at org.eclipse.jetty.util.component.AbstractLifeCycle.start(
> AbstractLifeCycle.java:68)
>
> at org.eclipse.jetty.util.component.ContainerLifeCycle.start(
> ContainerLifeCycle.java:132)
>
> at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(
> ContainerLifeCycle.java:114)
>
> at org.eclipse.jetty.server.handler.AbstractHandler.doStart(
> AbstractHandler.java:61)
>
> at 

Re: GWT Designer

[Colin Alworth]

If memory serves, the GWT Designer tool was never part of GWT itself, but 
was a component that could be installed in Eclipse, allowing for WYSIWYG UI 
design (in part by running something like dev mode while you were 
editing?). Changes that the author of the project made were reflected in 
standard source files (.java and .ui.xml) that GWT itself was able to 
compile - as such, a newer compiler version can likely still compile (with 
small or minimal changes to source) such an old project. I would suggest 
small steps in upgrading, to keep such changes (if any) manageable. 

If you're hoping to run GWT Designer itself, you probably need a very old 
version of eclipse - my memory here is that it wasn't used enough to be 
worth maintaining. The code still lives at 
https://github.com/gwt-plugins/gwt-designer, but I can't guess what it 
would take to bring it back to life. I have a memory of this being based on 
WindowBuilder, and some internal changes in WindowBuilder requiring 
substantial changes to the gwt-designer project, which never was done.

On Friday, October 27, 2023 at 3:19:36 PM UTC-5 sach...@gmail.com wrote:

> Hi All,
>
> We had created an application in 2014-2015. We had used GWT to design the 
> UI of our application.  Unfortunately, we have folded that project in 2017 
> . I wanted to showcase our project to a prospective customer and was keen 
> to know whether there is some way to migrate the project to the latest 
> version of GWT? 
>
> If that is not possible, I would like to display the screens which we had 
> designed using GWT Designer so that I can at the least create a story 
> around it.
>
> Looking forward to some positive response
>
> Please advise. 
>
> Thanks
> Sachin
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/e2bc0294-728c-45a5-b281-1649c2a1c828n%40googlegroups.com.

Re: GWT: Deserialize objects sent/received via websocket

[Colin Alworth]

Seeing traffic wouldn't hurt, but it would be easiest to discover by 
looking at code - finding "WebSocket" in the codebase, then seeing what the 
import is. Alternatively, the compiled JS will probably have some hints, 
depending on how it was built.

As to the authentication approach you clarified - if the client sends a 
POST before the websocket is created that performs the authentication, it 
is quite likely that the server responds by setting a cookie, and that all 
subsequent HTTP requests (including the websocket) are authenticated with 
that cookie. It is also possible that the websocket's binary blobs contain 
the credentials again, or more likely, the session ID. 

gRPC is indeed typically binary protobuf data... but gRPC can't be used in 
a browser in 2023. gRPC-web is a thing... which can't stream binary data, 
and can't stream data to the server (using the tooling provided by the gRPC 
project itself). There are alternative gRPC-web clients that can support 
streaming binary data _from_ the server, but in 2023 the fetch() API is 
still server streaming only, even with h2. There are even 
really-alternative gRPC clients for the browser that rely on websockets as 
well, but if you get in a situation where you want more than a small 
handful of concurrent streams the browser just hangs on new calls, so I 
can't recommend that, unless you use the websocket to replace the h2 
transport rather than using it per-stream (but now you've got more work to 
make sure you clean up streams promptly, and they aren't a lot of fun to 
debug).
On Friday, October 20, 2023 at 12:59:15 PM UTC-5 Thomas Broyer wrote:

> You could have a look at 
> https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit
>  
> to see what GWT-RPC exchanges look like and see if they match what you're 
> seeing. But they're not "binary".
>
> I didn't follow what gRPC (Google's RPC format: https://grpc.io/) looks 
> like on the web, but it's possible they use "binary" nowadays.
>
> On Friday, October 20, 2023 at 3:10:17 PM UTC+2 an.s...@gmail.com wrote:
>
>> Dear Colin,
>>
>> thanks for the quick response. I did observe the authentication approach 
>> via BurpSuite that allows me to investigate each HTTP / websocket request / 
>> response. From this perspective, I can see that upon submitting my 
>> credentials to the webapp, there is only one HTTP POST request from 
>> client-side that only includes the username. After this initial POST 
>> request, all the communication goes over websocket with binary blobs being 
>> exchanged. Hence, it is not easy for me to identify which GWT library class 
>> is in use.
>>
>> Is there any way how to get this information, (i.e. I could provide the 
>> URL of the endpoint I am talking to).
>>
>> Best,
>> André
>>
>> Colin Alworth schrieb am Freitag, 20. Oktober 2023 um 14:55:53 UTC+2:
>>
>>> While GWT offers websocket support, the only support is "now you can 
>>> send messages on a websocket" - no serialization is offered, beyond what 
>>> the browser itself provides (allowing sending a utf8 string, arraybuffers, 
>>> blobs, typedarrays, or arrayviews). How are you verifying messages 
>>> sent/received? If you are observing some 3-4 websocket frame handshake 
>>> messages on the websocket, that is probably some other GWT library in use - 
>>> which WebSocket class are you using?
>>>
>>> I maintain (and use in production) an rpc-over-websocket implementation 
>>> <https://github.com/vertispan/gwt-rpc>, but it does not explicitly 
>>> support authentication. Instead usually the first message authenticates 
>>> with the server, or HTTP headers are used to authenticate (potentially 
>>> using existing cookies) before the websocket is even initiated. So at least 
>>> we can probably rule out that implementation. 
>>>
>>> See https://developer.mozilla.org/en-US/docs/Web/API/WebSocket for more 
>>> information on what the browser's own WebSocket type offers.
>>>
>>> On Friday, October 20, 2023 at 7:31:03 AM UTC-5 an.s...@gmail.com wrote:
>>>
>>>> Hi,
>>>>
>>>> I am very new to GWT and have questions about the basic principles of 
>>>> how GWT via websockets work.
>>>>
>>>> I would like to analyze the authentication function of a given GWT web 
>>>> application. When authenticating with my credentials, I could identify 
>>>> that 
>>>> my credentials are sent via websocket in form of a binary blob. This most 
>>>> certainly is a serialized GWT object. The authentication seems to follow a 
>

Re: GWT: Deserialize objects sent/received via websocket

[Colin Alworth]

While GWT offers websocket support, the only support is "now you can send 
messages on a websocket" - no serialization is offered, beyond what the 
browser itself provides (allowing sending a utf8 string, arraybuffers, 
blobs, typedarrays, or arrayviews). How are you verifying messages 
sent/received? If you are observing some 3-4 websocket frame handshake 
messages on the websocket, that is probably some other GWT library in use - 
which WebSocket class are you using?

I maintain (and use in production) an rpc-over-websocket implementation 
, but it does not explicitly support 
authentication. Instead usually the first message authenticates with the 
server, or HTTP headers are used to authenticate (potentially using 
existing cookies) before the websocket is even initiated. So at least we 
can probably rule out that implementation. 

See https://developer.mozilla.org/en-US/docs/Web/API/WebSocket for more 
information on what the browser's own WebSocket type offers.

On Friday, October 20, 2023 at 7:31:03 AM UTC-5 an.s...@gmail.com wrote:

> Hi,
>
> I am very new to GWT and have questions about the basic principles of how 
> GWT via websockets work.
>
> I would like to analyze the authentication function of a given GWT web 
> application. When authenticating with my credentials, I could identify that 
> my credentials are sent via websocket in form of a binary blob. This most 
> certainly is a serialized GWT object. The authentication seems to follow a 
> protocol that involves 3-4 messages exchanged with the server-side.
>
> Hence, I strive to understand how the client-side transforms my textual 
> credentials (username / password) into this binary blob. Subsequently, I 
> would like to understand how I can deserialize messages coming from the 
> server in order to get a better idea of the messages exchanged and hence 
> the protocol.
>
> Thanks,
>
> André
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/4346318b-fe43-4454-ae90-c19bac156f55n%40googlegroups.com.

Re: com.ait.toolkit.core.Core not found in Gwt-tour

[Colin Alworth]

I'm broadly aware that gwt-tour exists (though it hasnt had an update in 8 
years), but I don't see any com.ait packages or references in it. On the 
other hand, I think com.ait.toolkit.core refers to 
https://github.com/dikalo/ahome-core/, which is a different thing entirely. 
It appears that ahome-core shadows a few GWT classes, which likely makes it 
incompatible with newer GWT versions - did you recently update GWT version 
and then start having this issue?

On Thursday, August 17, 2023 at 7:11:43 AM UTC-5 prasenji...@altizon.com 
wrote:

> GWT Module com.ait.toolkit.core.Core not found in project sources or 
> resources
>
> in Gwt-Tour library HopScotch.gwt.xml has inherited 
> com.ait.toolkit.core.Core which is not found bye goal 
> org.codehaus.mojo:gwt-maven-plugin
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/f0da1697-ff10-4351-8f0c-a5eb2cef163an%40googlegroups.com.

Re: [GWT] [ERROR] Hint: Check that your module inherits 'com.google.gwt.core.Core'

[Colin Alworth]

Tiberiu, the fact that it works in Eclipse strongly suggests to me that the 
ant classpath is different from the eclipse project classpath. That 
different configuration will lead to different results. This error is 
typically indicative of some other error happening (typically classpath 
related) - double check that, and add the "-strict" argument to the 
Compiler invocation to make sure you see any earlier errors as well (if 
any).

On Tuesday, August 8, 2023 at 4:48:56 PM UTC-5 tiberiu...@gmail.com wrote:

> Hello everyone,
>
> I just upgraded to GWT 2.10.0 from 2.8.1 and I receive the same error when 
> compiling through an Ant build.
>
> The code and scripts are identical and is compiling just fine with Java 
> 1.8, GWT 2.8.1 and Eclipse 4.17. However with Java 13 or 17, GWT 2.10.0 and 
> Eclipse 4.28 gives the error. Although in the second configuration it 
> compiles successfully through the Eclipse GWT plugin it does not compile 
> using the Ant build. But the GWT module is the same...
>
> What am I missing?
>
> Thanks you,
> Tiberiu
>
> On Friday, October 7, 2022 at 4:14:31 PM UTC+3 Thomas Broyer wrote:
>
>> See https://www.gwtproject.org/release-notes.html#Release_Notes_2_10_0
>> GWT *runs* on JDKs from 8 to 17; you can however only compile Java 11 –at 
>> most– source files (depending on -sourceLevel).
>>
>> When facing that kind of error, make sure you run with -failOnError (or 
>> its older name: -strict), and possibly use a more verbose -logLevel.
>>
>>
>> On Friday, October 7, 2022 at 2:51:17 PM UTC+2 ngf.ch...@gmail.com wrote:
>>
>>> Hello here.
>>> I would like to react for this threat. Would at this time (2022) gwt 
>>> supports java 12?
>>> For I am experiencing the error mentioned above.
>>> Thanks in advance.
>>>
>>>
>>> On Monday, May 20, 2019 at 12:59:25 AM UTC ma...@craig-mitchell.com 
>>> wrote:
>>>
 I don't believe GWT supports Java 12 yet.  I'd recommend just using 
 Java 8.

 And you might want to use the latest GWT version (2.8.2).

>>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/f80c2b1a-4d88-4b5c-9bb2-46ed557d0565n%40googlegroups.com.

Re: Partial super source? Possible?

[Colin Alworth]

I don't use String.format() a lot, even in the normal JVM, but based on the 
Javadoc it looks like we could add the format method, and delegate to a 
java.util.Formatter, but then leave that unimplemented by default. Then, 
downstream applications could more easily add that, without having to worry 
about keeping the rest of String.java up to date? 

Note also when trying to do anything beyond simple %s replacement, the 
java.util.Locale type exists in GWT emulation, but offers no instance 
methods outside of toString.

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/String.html#format(java.lang.String,java.lang.Object...)
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Formatter.html
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Locale.html


On Friday, July 21, 2023 at 4:38:24 AM UTC-5 Thomas Broyer wrote:

> GWT standard emulation is "just" super-source itself. You cannot "augment" 
> it, but you can "shadow" it by providing your own super-source version of 
> java.lang.String (copy from GWT and patch; and make sure it appears before 
> GWT's emulation in the source path – i.e. IIRC make sure the  
> comes before any  that would bring com.google.gwt.emul.Emulation). 
> This means you'll have to update your version whenever GWT updates its own.
> But only ever do this for an application, never for a library!
>
> On Thursday, July 20, 2023 at 1:46:15 PM UTC+2 Bruno Salmon wrote:
>
>> hi,
>>
>> If GWT emulates a Java class but not all methods, is it possible to 
>> provide a complement as a super source?
>>
>> For example, can I provide a super source for String.format() while 
>> keeping other String methods emulated by GWT?
>>
>> Thanks
>>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/86163e40-07e8-47de-9ce9-4abfd81df242n%40googlegroups.com.

Re: GWT compilation issue with jdk 17

[Colin Alworth]

There is community work underway 
 to update GWT-RPC itself to 
use jakarta.servlet packages, and the same idea could be applied to 
gwtplatform. Unfortunately, the gwtplatform.com domain is still owned, so 
any fork could not take over the groupid, but would need to pick a new one, 
which might cause some irritation when upgrading. I do see that the domain 
is scheduled to expire next year, but that probably isn't long enough to 
wait. It might be possible to contact the former owners to get permission 
for this work to be published as well. If you take that route, I'd be 
interested in being involved.

I've used the eclipse transformer before, and personally found it to be 
more trouble that it is worth. 


On Friday, July 21, 2023 at 8:03:56 AM UTC-5 NIKITAH wrote:

> Thank you Thomas for your guidance .
>
> On Friday, July 21, 2023 at 6:25:36 PM UTC+5:30 Thomas Broyer wrote:
>
>> On Friday, July 21, 2023 at 12:51:32 PM UTC+2 NIKITAH wrote:
>>
>> Yes , we are using  jakartaee-api : 9.0.0 . So can you please suggest 
>> which version of gwtp-dispatch-rest-*.jar will be compatible with Jakarta 
>> 9.0 ?
>>
>>
>> None!
>>
>> Repeating myself here: 
>>
>>
>>- GWTP is long dead; at least one year before the Javax/Jakarta mess 
>> was 
>>even announced (except for one never-released commit in Sept. 2018)
>>
>> Legacy projects should stay on "legacy" Java EE (or Jakarta EE 8), or 
>> migrate away from legacy/abandoned libs and frameworks that lock them to 
>> Java EE.
>>
>>
>> Now paraphrasing myself, you have to either:
>>
>>- stay on Jakarta EE 8 (or earlier Java EE)
>>- rewrite the whole thing to remove GWTP
>>- transform GWTP to Jakarta EE 9+ with the help of tools like Eclipse 
>>Transformer 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/c27903b8-a23b-4d9b-bc75-465e53b1d1ean%40googlegroups.com.

Re: DataPicker in GWT

[Colin Alworth]

It appears that this is specified as part of the DefaultCalendarView type, 
in the nested DateCell class's update(Date) method. I don't see an obvious 
way to override that, nor to replace the DatePicker.StandardCss type 
(package protected). Instead, you might implement CalendarView in your own 
way (perhaps copying some of or all of the existing content in 
DefaultCalendarView), then subclass DatePicker to pass your own instance to 
the protected constructor that takes a CalendarView instead?

As another option, can you clarify what additional styling you are trying 
to add? It might be possible to use the existing CSS styles to do this, or 
find another way to produce the same effect you're after?

On Tuesday, July 4, 2023 at 11:32:20 AM UTC-5 zarat.u...@gmail.com wrote:

> How can I set an additional selector for a date that has the "datePicker 
> DayIsFiller" selector in the GWT DatePicker class?
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/1c8144a9-c7bd-4f3b-8406-5ba9d8bf9dfdn%40googlegroups.com.

Re: GWT war file deployment issue on Tomcat 9

[Colin Alworth]

It looks as though the war file that was deployed was built after Super Dev 
Mode had been started, but before the production build had been performed, 
so the generated JS only works with a local development server. Try a clean 
build, without starting dev mode?

If this still doesn't work, can you share more details about exactly how 
you build the project for production?

On Monday, July 3, 2023 at 11:33:26 AM UTC-5 jiny...@gmail.com wrote:

> We were notified that we need to move our applications off from Weblogic 
> 14 server to OpenShift platform. The first task is to make sure the GWT 
> application works in local development environment with Tomcat 9 server. 
>
> We can run the GWT application by starting Tomcat 9 server from Eclipse 
> using WTP. However, when we tried to deploy the war file in the tomcat 9 
> deployment folder "webapps" and tried to access to the site url as below, 
> an dialog is displayed as attached asking to get code server ready first. 
> The war file was created from the war directory after GWT compilation 
> process is finished. 
>
>
> http://127.0.0.1:8080/aries
>
> GWT 2.9
> JDK 11
> Eclipse 4,15
> GWT plugin 3
>
>
> Please help shed some lights on this deployment issue.
>
> thanks!
> Jenny
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/cb206781-0c0b-47d2-815c-28a5c43f5226n%40googlegroups.com.

Re: GWT compilation error with JDK 11

[Colin Alworth]

If the class can't be found, something is wrong with your gwt-dev, or the 
gwt-dev isn't on the classpath, or more details from the error message will 
indicate why the Compiler class couldn't be loaded. 

Please file a bug with more details (logs, full error message, other 
details about differences between the working computer and non-working 
computer) at https://github.com/gwt-plugins/gwt-eclipse-plugin/ so 
contributors there can take a closer look?

On Sunday, July 2, 2023 at 2:28:44 PM UTC-5 jiny...@gmail.com wrote:

> I tried to reinstall Eclipse again and GWT 3 plugin again from Eclipse 
> market, downloaded and reinstalled gwt 2.9 for the project, however, I 
> still encountered the error below.
> It is so weird, the project configuration in eclipse works in my old 
> laptop, not in the new one though it both has windows 10 installed.
>
> Error: Could not find or load main class com.google.gwt.dev.Compiler
>
> eclipse-jee-2020-06-R-win32-x86_64
> GWT Plugin 3.0
> gwt-2.9.0
>
> Please see attached for the java build path dialog in eclipse.
>
> Any idea about resolving this error? Please help shed some light on this 
> problem.
>
> Your help is much appreciated!
> Jenny
>
>
> On Friday, June 16, 2023 at 3:25:42 PM UTC-5 Ying Jin wrote:
>
>> Thanks for your reply. Please see attached for the GWT lib specified in 
>> the java build path in Eclipse. I tried to compile it with JDK 8 and it 
>> didn't work either. 
>> The same project configuration in Eclipse worked in my old laptop, but 
>> not in my new laptop. The Eclipse in the new laptop is a copy of the 
>> Eclipse installed in the old laptop.
>>
>> In addition, I also tried to  copy the "gwt-dev.jar" from the old laptop 
>> to the new one, but the compilation still gave me the following error.
>>
>> Error: Could not find or load main class com.google.gwt.dev.Compiler
>>
>> The project was compiled by using GWT->Compile option provided by the GWT 
>> Plugin installed in Eclipse.
>>
>> Version: 2020-06 (4.16.0)
>> GWT Plugin version: 3.0
>>
>> Your help is greatly appreciated!
>>
>> thanks,
>> Jenny
>> On Friday, June 16, 2023 at 12:33:18 PM UTC-5 Colin Alworth wrote:
>>
>>> GWT 2.9 should support running on Java 11, both running on JDK 11 and 
>>> compiling Java 11 sources.
>>>
>>> Without other information, it sounds like there is a problem with your 
>>> copy of gwt-dev.jar - the jar might be corrupt, or somehow not on your 
>>> classpath? 
>>>
>>> Can you verify that the jar is present and correct, and share more 
>>> specifics of how you are building?
>>>
>>> On Thursday, June 15, 2023 at 6:00:43 PM UTC-5 jiny...@gmail.com wrote:
>>>
>>>> Hello,
>>>>
>>>> I tried to compile our GWT 2.9 project with JDK 11, but encountered the 
>>>> following error:
>>>>
>>>> Error: Could not find or load main class com.google.gwt.dev.Compiler
>>>>
>>>> Caused by: java.lang.ClassNotFoundException: com.google.gwt.dev.Compiler
>>>>
>>>> BTW, the Eclipse version is  Version: 2020-06 (4.16.0). 
>>>>
>>>> Please help shed some lights on this issue.
>>>>
>>>> thanks,
>>>> Jenny
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/25ab65da-b3a5-4458-955c-248dc64d97adn%40googlegroups.com.

Re: Devmode compilation

[Colin Alworth]

Your stack trace stops just before where the issue is happening, but the 
GWT compiler believes that you are using code in an impossible way, and is 
forced to emit an error message to correctly compile out impossible code. 
Roughly, the "throw ClassCastException unless null" check means that there 
is some cast that must always fail - nothing ever implements the interface, 
or nothing ever calls the constructor. In draft mode, the compiler couldn't 
prove this, but when you were building for production, the compiler is 
confident that this is impossible.

What is likely happening is that you are doing an unchecked cast of some 
kind, possibly a native JS type to a @JsType-annotated interface that isn't 
marked as isNative=true or the like. In this scenario, the compiler knows 
that no native types could implement the interface, and since it sees no 
non-native types that implement it, there must be no such types, so any 
calls to the interface's methods are actually errors. Further, any code 
that would come after such a method call can never be called.

Look at the next frame up the stack trace, and see if you can tell what 
method call is being optimized out in this way. Probably you'll see that it 
either comes from a class or interface that can't be directly instantiated, 
but somehow (likely an unchecked cast) you have an instance of that type 
anyway. 

As to correctness, this is a good check to have, as it removes impossible 
code, which _usually_ you don't want to have. Incorrect code can often lead 
to impossible code, but there are many reasonable cases where this check 
should be emitted, so it isnt necessarily wrong for a compiled application 
to have this.

On Friday, June 16, 2023 at 2:25:53 PM UTC-5 nikola wrote:

> Some class cast exception...
>
> Showing dialog with error2 Error: java.lang.ClassCastException
> at ClassCastException.createError (lw_ui-0.js:2052:10)
> at ClassCastException.initializeBackingError (lw_ui-0.js:2078:40)
> at ClassCastException.Throwable_0 (lw_ui-0.js:2017:8)
> at ClassCastException.Exception_0 (lw_ui-0.js:2095:15)
> at ClassCastException.RuntimeException_0 (lw_ui-0.js:16350:15)
> at new ClassCastException (lw_ui-0.js:217687:22)
> at checkCriticalType (lw_ui-0.js:225523:16)
> at throwClassCastExceptionUnlessNull (lw_ui-0.js:272:3)
>
> It works with -draftCompile. What we are potentially losing having code 
> compiled with -draftCompile? Is it safe to have it on production?
>
> On Friday, June 16, 2023 at 7:36:50 PM UTC+2 Colin Alworth wrote:
>
>> Super Dev Mode skips many optimizations, both to decrease compile times 
>> and also to make incremental compilations possible - it isn't possible to 
>> make SDM behave the exact same as a production compile. One way you can get 
>> close is to specify -draftCompile (how you specify it may vary based on how 
>> you run the compiler) so that the production build skips many optimizations.
>>
>> Can you elaborate on what the strange error is?
>>
>> On Friday, June 16, 2023 at 11:32:37 AM UTC-5 nikola wrote:
>>
>>> Hello,
>>>
>>> The code has passed in development mode but when it's deployed I got an 
>>> strange error. Is there a difference in generated compiled code when 
>>> deployed and code in development mode ?
>>> And if true, where can I change that setting to have it equals
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/9b14eb34-183d-49c6-bbb3-9748d41c514cn%40googlegroups.com.

Re: Devmode compilation

[Colin Alworth]

Super Dev Mode skips many optimizations, both to decrease compile times and 
also to make incremental compilations possible - it isn't possible to make 
SDM behave the exact same as a production compile. One way you can get 
close is to specify -draftCompile (how you specify it may vary based on how 
you run the compiler) so that the production build skips many optimizations.

Can you elaborate on what the strange error is?

On Friday, June 16, 2023 at 11:32:37 AM UTC-5 nikola wrote:

> Hello,
>
> The code has passed in development mode but when it's deployed I got an 
> strange error. Is there a difference in generated compiled code when 
> deployed and code in development mode ?
> And if true, where can I change that setting to have it equals
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/e658fb10-02eb-48b8-b1a3-d6269c4fed9cn%40googlegroups.com.

Re: GWT compilation error with JDK 11

[Colin Alworth]

GWT 2.9 should support running on Java 11, both running on JDK 11 and 
compiling Java 11 sources.

Without other information, it sounds like there is a problem with your copy 
of gwt-dev.jar - the jar might be corrupt, or somehow not on your 
classpath? 

Can you verify that the jar is present and correct, and share more 
specifics of how you are building?

On Thursday, June 15, 2023 at 6:00:43 PM UTC-5 jiny...@gmail.com wrote:

> Hello,
>
> I tried to compile our GWT 2.9 project with JDK 11, but encountered the 
> following error:
>
> Error: Could not find or load main class com.google.gwt.dev.Compiler
>
> Caused by: java.lang.ClassNotFoundException: com.google.gwt.dev.Compiler
>
> BTW, the Eclipse version is  Version: 2020-06 (4.16.0). 
>
> Please help shed some lights on this issue.
>
> thanks,
> Jenny
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/531a2b90-776a-4ed3-a797-8f9c5f4b5be5n%40googlegroups.com.

[gwt-contrib] Preparing for GWT 2.11 release

[Colin Alworth]

There have been a few suggestions of making a release in the near future, 
and it seemed like it might be a good idea to summarize pending 
development, ask for help to land these, and see if anything else needs to 
be addressed before shipping.


   - There is a pending branch (not yet a PR for GWT itself) working on 
   adding a new gwt-servlet-jakarta.jar and requestfactory-server-jakarta.jar 
   as part of https://github.com/gwtproject/gwt/issues/9727. There is no plan 
   at this time to update the DevMode server to Jakarta, though that will 
   eventually be inevitable if we move to a newer version of Jetty. Work on 
   this can be found at https://github.com/niloc132/gwt/pull/3.
   - There is a pending fix for eliminating a false positive from using 
   some internals of protobuf to deobfuscate client side exceptions 
   https://github.com/gwtproject/gwt/pull/9785. This is probably safe to land 
   without more testing, but none of the reporters of this bug have verified 
   the fix.
   - There's a pending fix for a bug in type unions, which can be caused by 
   some ternary expressions and var type declarations 
   https://github.com/gwtproject/gwt/pull/9799. A review found a few 
   oversights in testing, and I'd appreciate another look.
   - There's a pending fix for a bug where debugging in firefox when 
   assertions are enabled (for example in SDM). It turns out the bug can 
   happen in other cases too in more subtle ways. A draft fix it at 
   https://github.com/gwtproject/gwt/pull/9800.
   - GWT itself can now be built on Java 11, but not yet 17. There are a 
   few changes pending that will permit this. Additionally, this will enable 
   adding more Java 9-11 JRE emulation, see the list at 
   https://github.com/gwtproject/gwt/issues/9547.


Finally, we have an open question about future Java 8 support. Beyond this 
release, we likely will no longer support running the compiler in Java 8, 
which will enable adding support for Java 12-17 language features. We can 
likely still build jars that will run on a Java 8 server, but just can't 
compile newer JS. To that end, this 2.11 release branch may be longer-lived 
than usual, depending on feedback and support to continue bugfix releases 
after 2.12 eventually ships.

Are there other changes that 2.11 should included, or other considerations 
for this release cycle?

-- 
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/18e9c767-a2e8-42e2-9b6c-764dc0088629n%40googlegroups.com.

Re: Entry point

[Colin Alworth]

The entrypoint is supposed to function as the start of the application - 
how do you "enter" into it. You likely don't encounter the same entrypoint 
more than once as the app is being used, and any/all entrypoints will run 
right at page load. Technically each of what you describe is probably 
possible, but it seems very likely that you wouldn't want to use an 
entrypoint to manage a dialog that is opened by clicking a button.

Typically, the entrypoint is used like a java public static void main 
method - just one, only do enough in it to start the application.

On Sunday, May 14, 2023 at 11:44:47 PM UTC-5 ronjos...@gmail.com wrote:

> Thank you Colin for responding , 
>
> Can we use the entry point for some specific page or widget in the 
> application?
> e.g. There is a dialog in the application on which if clicked on edit 
> button , we see another dialog on which there is a button to add files. 
> Can we use the entry point to drag and drop files over the area of that 
> add file button ?
>
> Regards
> Ronit
>
> On Monday, 15 May 2023 at 04:40:28 UTC+5:30 Colin Alworth wrote:
>
>> While it is technically possible to have more than one EntryPoint 
>> declared in your .gwt.xml files(s), order might be hard to control 
>> precisely. I believe the order is deterministic, but not strictly defined 
>> by the compiler (likely the order in which entry-point> tags are 
>> encountered when parsing .gwt.xml files, but since they are permitted to 
>> have cyclical dependencies, this is not always obvious).
>>
>> With that said, this can be a good way to compile multiple independent 
>> applications into a single output JS (so that they avoid sending the same  
>> classes to the browser multiple times. I've seen this done with a 
>> conditional at the top of each entrypoint, to that way one or more 
>> entrypoint can run at page load automatically, and each enhance the part of 
>> the page that matters specifically to them. Ideally in this case, order of 
>> execution will not matter, so the above concern won't apply.
>>
>> On Sunday, May 14, 2023 at 5:57:20 PM UTC-5 ronjos...@gmail.com wrote:
>>
>>> Hello Team,
>>>
>>> I am new to GWT and working on an existing system.
>>>
>>> My application has already got an entry point. Can I have one more 
>>> implementation of the Entrypoint ?
>>>
>>> Thanks in advance 
>>> Ronit
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/f17f59a2-1090-4c8d-bf9c-663fe72dfe87n%40googlegroups.com.

Re: Entry point

[Colin Alworth]

While it is technically possible to have more than one EntryPoint declared 
in your .gwt.xml files(s), order might be hard to control precisely. I 
believe the order is deterministic, but not strictly defined by the 
compiler (likely the order in which entry-point> tags are encountered when 
parsing .gwt.xml files, but since they are permitted to have cyclical 
dependencies, this is not always obvious).

With that said, this can be a good way to compile multiple independent 
applications into a single output JS (so that they avoid sending the same  
classes to the browser multiple times. I've seen this done with a 
conditional at the top of each entrypoint, to that way one or more 
entrypoint can run at page load automatically, and each enhance the part of 
the page that matters specifically to them. Ideally in this case, order of 
execution will not matter, so the above concern won't apply.

On Sunday, May 14, 2023 at 5:57:20 PM UTC-5 ronjos...@gmail.com wrote:

> Hello Team,
>
> I am new to GWT and working on an existing system.
>
> My application has already got an entry point. Can I have one more 
> implementation of the Entrypoint ?
>
> Thanks in advance 
> Ronit
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/3399c7a4-4221-4f91-a921-a88ede7dd5a3n%40googlegroups.com.

Re: Commitment regarding Jakarta

[Colin Alworth]

Several volunteer community members are indeed committed to this.

There was another recent discussion on this mailing list (just four topics 
down) that you can see at 
https://groups.google.com/g/google-web-toolkit/c/vBSKMgdZz1w - I directed 
the user to the discussion on our issue tracker at 
https://github.com/gwtproject/gwt/issues/9727 - you might also be 
interested in the side discussion happening in a pull request at 
https://github.com/niloc132/gwt/pull/3 on specfics of how to achieve this 
painlessly. 

Also as discussed in 9727, there is an early prototype deployed at 
https://repo.vertispan.com/gwt-snapshot/ with version 
2.11.0-jakarta-SNAPSHOT that you are free to test.

If you or your company are interested in contributing, those are good 
places to offer your time or to otherwise assist the developers who are 
working on this. As an open source project with no real funding behind it, 
this will proceed at the pace of the community members who are able to 
engage and contribute.

On Wednesday, May 3, 2023 at 8:17:49 AM UTC-5 aikic...@gmail.com wrote:

> Hello,
>
> I would like to know if there is any kind of commitment from the GWT 
> project to move to Jakarta in a nearby future. We have over 50 apps, some 
> larger than others, built with GWT, so this is very important to us. Moving 
> away from GWT would be a huge amount of work.
>
> Thanks in advance,
>
> Christian
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/d0ee4f44-9465-4133-a682-077ec4556143n%40googlegroups.com.

Re: HTTP Method Override

[Colin Alworth]

I think Thomas is on the right track - the tester ran the query with the 
method override headers indicating “PUT” instead of “POST”, and saw that 
the response came back “200 OK”, and assumed that the attack had worked. 
Instead what happened is that gwt-rpc couldn’t understand the request, and 
sent back an error - see the “//EX” prefix on the last line of the reply - 
but since it always leaves a 200 status code and, the tester believed that 
the request was handled properly. 

It might be important to communicate with them about what gwt-rpc is and 
does, and clarify what the attack that they believe succeeded should have 
done (and confirm with your own application that it did not), and likewise 
confirm their expectations for an HTTP call like this (did they expect that 
for any unknown header that the call would simply fail, etc). 




On Wednesday, April 26, 2023 at 5:32:09 AM UTC-5 Thomas Broyer wrote:

> Those headers don't come from GWT itself, they've been added by the 
> application or some library/framework it uses on top of GWT. It looks like 
> that app is using something like gwt-dispatch, gwt-sl or spring4gwt or 
> something like that, but maybe homemade.
> What I'd do to tell if they're actually used/useful (in this specific 
> case!):
>
>1. open the WAR and look at the WEB-INF/web.xml (or possibly some 
>other configuration files if it uses, e.g., Spring or whatever) to try to 
>find the servlet class mapped to the /dispatch/GetCompaniesAction path 
>(could be as easy as a class named GetCompaniesAction)
>2. Decompile that class (using javap or an IDE) and look for a 
>doPut(ServletRequest,ServletResponse) method. Possibly go up the class 
>hierarchy until you find the RemoteServiceServlet.
>
> Depending on the application, that may not lead to anything, but if 
> there's a doPut, changes are it will be used.
>
> Also look at the WEB-INF/web.xml for servlet filters, and at other 
> configuration files (Spring mainly, if used) to see if there'd be some 
> filter dedicated to handling those kind of headers.
>
> Anyway, as said: this doesn't come from GWT itself.
>
> (actually, I'd be more concerned about a Firefox 98 being used )
>
> Now I don't know Fortify WebInspect so maybe I'm also misinterpreting 
> what's reported here: if this is a request made by Fortify WebInspect 
> (rather than one made "on the wild" and intercepted by the solution) then I 
> don't see why it'd be reported as a vulnerability, it could be that the 
> server completely ignores the headers, right?
>
> On Wednesday, April 26, 2023 at 11:37:00 AM UTC+2 cyclop...@gmail.com 
> wrote:
>
>> We have a web app (GWT 2.7 ) from a vendor and we don't have any source 
>> codes.
>> Now we faced a vulnerability about *HTTP Method Override* for http 
>> header below
>>
>> *X-HTTP-METHOD*
>>
>> *X-HTTP-Method-Override*
>> *X-METHOD-OVERRIDE*
>>
>> Fortify WebInspect report
>>
>> Attack Request:
>> POST /CustomPortal/dispatch/GetCompaniesAction HTTP/1.1
>> Host: 10.4.202.26:8861
>> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) 
>> Gecko/20100101 Firefox/98.0
>> Accept: */*
>> Accept-Language: en-US,en;q=0.5
>> Accept-Encoding: gzip, deflate
>> Content-Type: text/x-gwt-rpc; charset=utf-8
>> X-GWT-Permutation: 3EE8E625356CC9E9E724C10285609299
>> X-GWT-Module-Base: https://10.4.202.26:8861/CustomPortal/custom/
>> Referer: https://10.4.202.26:8861/CustomPortal/
>> Content-Length: 311
>> Origin: https://10.4.202.26:8861
>> Pragma: no-cache
>> X-HTTP-METHOD: PUT
>> X-HTTP-Method-Override: PUT
>> X-METHOD-OVERRIDE: PUT
>> Connection: Keep-Alive
>> X-WIPP: AscVersion=22.2.0TRUNCATED...
>>
>> Attack Response:
>> HTTP/1.1 200 OK
>> Set-Cookie: JSESSIONIDSSO=; path=/; HttpOnly; Max-Age=0; Expires=Thu, 
>> 01-Jan-1970 00:00:00 GMT
>> X-XSS-Protection: 1; mode=block
>> X-Frame-Options: SAMEORIGIN
>> Referrer-Policy: strict-origin-when-cross-origin
>> Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 
>> 'none'; style-src 'self' 'unsafe-inline'; img-src 'self'; scriptsrc
>> 'self' 'unsafe-inline' 'unsafe-eval';connect-src 'self' https: localhost;
>> Content-Disposition: attachment
>> Date: Fri, 21 Apr 2023 06:10:56 GMT
>> Connection: keep-alive
>> X-Content-Type-Options: nosniff
>> Content-Length: 177
>> Content-Type: application/json;charset=utf-8
>> //EX[3,0,2,1,0,1,["com...TRUNCATED...
>>
>> Is there any way to disable these headers ?
>> Or is there any description to let me tell user this is NOT vulnerability 
>> ?
>>
>> AP server is JBoss EAP 7.3.8 GA
>>
>> Many thx!
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/87c805d5-53c3-498b-bc27-ac6ea3728861n%40googlegroups.com.

Re: GWT 2.10.0 and TLD/JAR Scanner Error

[Colin Alworth]

I think a little more detail could help us to identify the problem, but to 
start with, gwt-dev should never be on your server classpath - and neither 
should its dependencies. If you have gwt-dev.jar or GWT's preferred 
apache-jsp.jar on your server classpath, you should remove that (either 
build your client separately from your server code, or exclude those 
dependencies from being provided at runtime by maven). Given that you are 
using WebLogic rather than Tomcat already, I'm guessing that this is the 
source of your problem.
On Friday, April 28, 2023 at 3:45:27 PM UTC-5 Aynesh Patel wrote:

> Hello,
>
> I have a GWT 2.10.0 project compiled in Java 11, built with Maven 3.8.4 
> through the GWT-maven-plugin, and deployed to a WebLogic 14c server. 
> Recently I have seen errors related to the Tomcat JAR scanner and the 
> embedded server utilized in development mode. The application was working 
> but after the upgrade to version 2.10.0, errors fill the server out log in 
> WebLogic that the Tomcat StandardJarScanner failed to scan JAR files from 
> the classloader hierarchy along with a silent failure of the application 
> itself. After ensuring GWT was starting in Production Mode, I added the 
> following elements to the configuration section of the plugin to ensure the 
> server would not start up:
>
> true
> 
> -noincremental
> 
>
> After recompiling with these changes the application was able to function 
> normally once again but the errors regarding the JAR scanner being unable 
> to scan from the classloader hierarchy remained. The JARs it attempted to 
> scan were ones that are not part of the application nor in any of the 
> dependency trees of the dependencies of the gwt-maven-plugin.
>
> I want to disable that JAR scanning and the errors it produces when the 
> application is started. I attempted to do so by adding a context.xml to the 
> webapp/META-INF to the scanning with configuration to limit the scanner but 
> it did not seem to have an effect. Here are logs for the errors happening 
> in the out file for the WL server the application is deployed to:
>
> Failed to scan  from classloader hierarchy
> Java.io.IOException: java.lang.reflect.InvocationTargetException
> at 
> org.apache.tomcat.util.compat.Jre9Compat.jarFileNewInstance(Jre9Compat.java:209)
> at org.apache.tomcat.util.scan.JarFileUrlJar.(JarFileUrlJar.java:65)
> at org.apache.tomcat.util.scan.JarFactory.newInstance(JarFactory.java:49)
> at 
> org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:387)
> at 
> org.apache.tomcat.util.scan.StandardJarScanner.processURLs(StandardJarScanner.java:322)
> at 
> org.apache.tomcat.util.scan.StandardJarScanner.doScanClassPath(StandardJarScanner.java:284)
> at 
> org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:235)
> at org.apache.jasper.servlet.TldScanner.scanJars(TldScanner.java:262)
> at org.apache.jasper.servlet.TldScanner.scan(TldScanner.java:104)
> at 
> org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:101)
> at 
> weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1428)
> ...
>
>
> Additionally, in the server log file there is this outputted on startup:
>  back to default JarScanner implementation.>
>
> This link (
> https://stackoverflow.com/questions/66689374/spring-boot-with-jetty-disable-o-a-tomcat-util-scan-standardjarscanner)
>  
> mentioned that the org.apache.tomcat.util.scan.StandardJarScanner can 
> originate from apache-jsp JARs which gwt-dev 2.10.0 has a dependency. I 
> confirmed this in my IDE and maven repository but I have been unable to 
> prevent the scanning of the classpath hierarchy for TLDs. Is there a way to 
> disable this scanning of TLDs and JAR files from the classloader hierarchy?
>
> Help is very much appreciated!
>
> Thank you,
> Aynesh Patel
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/4311a9f0-a0df-465c-b836-ab02988207c8n%40googlegroups.com.

Re: Building artifact without clutter

[Colin Alworth]

(Might be a better post for 
https://groups.google.com/g/google-web-toolkit-contributors)

The maven artifacts require one more step to deploy, either to your maven 
local cache, or to an artifact server you can deploy to. Use the 
maven/push-gwtproject.sh script (see 
https://github.com/gwtproject/gwt/blob/main/maven/push-gwtproject.sh) and 
provide it a version, and optionally a gpg passphrase, maven repository 
id/url.

See also the nightly snapshot build code, which deploys in this way, by 
setting those values as env vars (except gpg passphrase) 
https://github.com/gwtproject/gwt/blob/9f175af25edc9713147d3994c59b4760c9a5346b/.github/workflows/full-check.yml#L95-L108


On Tuesday, April 18, 2023 at 11:09:47 AM UTC-5 mirosl...@ataccama.com 
wrote:

> Hello,
>
> I cloned gwt repo, I followed the steps and I created my own local 
> artifact by using "ant clean dist" or "and clean dist-dev".
>
> Everything works, BUT I would like to build artifact that is similar to 
> official released artifacts like this 
> .
>
> Local artifacts have a lot of clutter that I don't need ant it actually 
> causes problems and I was not able to find some parameters or some 
> guideline how to achieve the result. On the screenshot you can see local 
> artifact (left) and the one from official release.
>
> How can I build the artifact without the clutter please?
>
> [image: gwtDifference.png]
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/9c86f1bd-9c4f-46f2-ad42-0e926c028b00n%40googlegroups.com.

Re: Privacy Violation with SSN

[Colin Alworth]

I haven't seen this come up before in a scan like this, thanks for sharing!

This is due to the compiler, but rather than obfuscation, this is due to 
the compiler solving for a constant value rather than doing the math at 
runtime. This same constant appears in the GWT showcase as well, at 
https://samples.gwtproject.org/samples/Showcase/Showcase.html in the 
https://samples.gwtproject.org/samples/Showcase/showcase/deferredjs/5F20F7F6874DB82B437E6EA4319E4E9B/47.cache.js
 
file.

function 
Hmc(a,b,c,d,e,f){Gmc();this.a=e;Th(a,Dwc(b,c,d,e,f));a.db==-1?(Sbc(),Idc(a.hb,13119|(a.hb.__eventBits||0))):(a.db|=13119)}

This is slightly different from yours, and not just in the obfuscation - I 
suspect that you have emulated stack traces enabled, which should allow you 
to check the value of the NWl and RWk constants to confirm - they should be 
the "stack trace element" information, like class+method name, line number 
etc.

In this case, that particular line comes from Image.java's constructor. 
That calls the constructor of the inner class UnclippedState, which has 
these lines:
UnclippedState(Image image) {
  image.replaceElement(Document.get().createImageElement());
  // We are working around an IE race condition that can make the image
  // incorrectly cache itself if the load event is assigned at the same 
time
  // as the image is added to the dom.
  Event.sinkEvents(image.getElement(), Event.ONLOAD);


  // Todo(ecc) this could be more efficient overall.
  image.sinkEvents(Event.ONCLICK | Event.ONDBLCLICK | Event.MOUSEEVENTS 
| Event.ONLOAD
  | Event.ONERROR | Event.ONMOUSEWHEEL | Event.TOUCHEVENTS | 
Event.GESTUREEVENTS);
}

That chained | expression results in the number you're seeing. Then, that 
value is passed to Widget.sinkEvents(), which looks like this:
  @Override
  public void sinkEvents(int eventBitsToAdd) {
if (isOrWasAttached()) {
  super.sinkEvents(eventBitsToAdd);
} else {
  eventsToSink |= eventBitsToAdd;
}
  }


The isOrWasAttached() call is a comparison of a field to -1, and a ternary 
is used instead of an if/else for this:
a.db==-1 ? 
(Sbc(),Idc(a.hb,13119|(a.hb.__eventBits||0))):
(a.db|=13119)

Now it becomes clear that "this.eventsToSink" is "a.db", and 
"eventBitsToAdd" is the constant int 13119.

Links to github source to confirm:
https://github.com/gwtproject/gwt/blob/1671fc2730e23b371962f482830c090b901ea54e/user/src/com/google/gwt/user/client/ui/Image.java#L371-L381
https://github.com/gwtproject/gwt/blob/1671fc2730e23b371962f482830c090b901ea54e/user/src/com/google/gwt/user/client/ui/Widget.java#L238-L245

So - this is not a SSN, but just happens to have the same number of digits. 
On Tuesday, April 11, 2023 at 1:35:58 PM UTC-5 cyclop...@gmail.com wrote:

> We hava a GWT project, and user use WebInspect to scan, then they found a 
> critial issue as below in the file 30.cache.js
> [image: Snap10.jpg]
> [image: ssn.png]
>
> What's the "13119" ?
> Is that bacause GWT obfuscate ?
> Sorry we don't have the source codes of this GWT project (We just have WAR 
> file only)
>
> Many thx.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/562db861-68c1-43d8-81fa-65ac79d00681n%40googlegroups.com.

Re: page navigation

[Colin Alworth]

It is difficult to be sure what you are asking, but to navigate 
automatically to a new URL, you might just want 
Window.Location..assign(newUrl) or Window.Location.replace(newUrl), 
depending on exactly what behavior you want to have in your user's browser 
history. Alternatively if you are using activities/places or history 
tokens, you should use that specific api to send the user to the correct 
view.

On Tuesday, April 11, 2023 at 1:35:58 PM UTC-5 KEERTHIKA C wrote:

> after creating the login page on the succesfull login the page has to 
> locate to the another page in gwt give me some sample

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/e133af6b-0013-4c56-97f7-1232862b3914n%40googlegroups.com.

Re: Jakarta EE 9 support in GWT

[Colin Alworth]

The work on this topic is being discussed on that ticket and related pull 
requests. In short, if there is community support to implement and test 
this, it will be present in a future release.

Please try the test builds already discussed there, and consider joining 
the discussion to help contribute to the work.

On Monday, April 3, 2023 at 2:44:48 AM UTC-5 mickn...@gmail.com wrote:

> Hi,
>
> I'm working on a large Java library that utilizes both Spring and GWT. We 
> want to move to Spring 6 as soon as possible but currently cannot do this 
> because GWT 2.10 uses javax instead of jakarta.
>
> Some work towards supporting jakarta has been discussed here - 
> https://github.com/gwtproject/gwt/issues/9727.
>
> Are there any intentions to support Jakarta in an upcoming GWT release?
>
> Thanks,
> Mike.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/11047a56-f8ef-40ee-8896-633facf10153n%40googlegroups.com.

Re: Question about setting GWT RPC timeout

[Colin Alworth]

What you're looking for is a way to re-try requests in the case where the 
server is unreachable, which is not something that HTTP or the browser 
gives you automatically. If you had a proxy, but the server itself was 
down, the proxy would likely return a 503 service unavailable status, which 
the client could use to retry until the service was available (which might 
only happen for a certain number of seconds or a certain number of tries). 
It might also be possible for a proxy to wait and retry the upstream server 
until it was available, but I can't think of a proxy right now with that 
feature.

HTTP itself doesn't have a timeout feature at all either. The timeout that 
you're setting on the client side is a simple GWT Timer, if the request 
hasn't finished (either in success or failure), it cancels the upstream 
request and presents the failure you're seeing to the client.

Be a little careful when implementing a retry mechanism, as it is possible 
that the call made it to the server, and the server performed the action, 
but the client lost internet connection while the response was on its way 
to the client - that is, retrying a non-idempotent or expensive action may 
cause problems you weren't expecting. A status code of 0 is usually the 
client's way of saying "I wasn't able to get any reply from the server for 
some reason" - taking that information and trying to do something simple 
and idempotent until a server connection can be reestablished lets you know 
that the server and network are both working again, followed by some "did 
my last action succeed" before trying again (or just let the user dismiss 
the message and try again) will help mitigate this class of issues. A proxy 
sending back a 503 is a safer way to be sure that the network connection is 
good, but only the server is down, so you can retry - but be aware that 
technically there might be a network issue between the proxy and server, 
though this is much less likely.

Good luck,
Colin

On Thursday, April 6, 2023 at 7:05:53 AM UTC-5 Dmitri wrote:

> Dear Colin
>
> Thank you so much for your advice. I'll take a closer look at those areas.
>
> Just a little clarification: The server is not running at all. Both 
> exceptions are generated from the client only with different timeout 
> settings when it cannot reach the server.
> When the server is running - no problems in both cases. The purpose of the 
> code is to make the client wait longer when the server is unreachable due 
> to temporary communication problems.
>
> PS there are some typos in the codes I provide which I made when clean-up 
> for posting., Please ignore them.
> Thank you again
>
> Best regards
> Dmitri
>
>
> On Thu, Apr 6, 2023 at 9:49 PM Colin Alworth  wrote:
>
>> I believe you're experiencing different timeouts in different cases. That 
>> is, the problem you're facing of a short timeout before you use your 
>> RPC_TIMEOUT_MS is a server-side timeout (or potentially a proxy?), but 
>> after you set a client-side timeout, the client is observing that the 
>> server is taking too long, and terminating the call from its side, 
>> resulting in the RequestTimeoutException.
>>
>> To confirm this, try setting the client-side timeout to something like 
>> one minute, 60_000, and see that the error returns to the old message you 
>> were seeing. A timeout set like this does not guarantee that the server 
>> stops processing the request, only that the client stops waiting for it, 
>> and it may not be appropriate for your use case at all.
>>
>> With the client-side timeout set to a reasonable amount or entirely 
>> removed, take a closer look at the error message you're getting from the 
>> server, and any server or proxy logs you're getting. If there is a proxy, 
>> see if you can connect directly to the server to rule out the proxy setting 
>> this short timeout. Very likely this is a configuration on the server/proxy 
>> that can be change to suit your requirements.
>>
>> On Thursday, April 6, 2023 at 2:26:31 AM UTC-5 Dmitri wrote:
>>
>>> Dear gurus,
>>>
>>> I'm learning Java and GWT and I'm facing a problem with setting timeout 
>>> for PRC calls. I want to extend the RPC timeout before the client reports a 
>>> failure. The code I'm using is attached below.
>>>
>>> I'm running a client in firefox and experience the following problem:
>>>
>>> I want to achieve a timeout of 20-30 seconds. However I can set the 
>>> timeout (RPC_TIMEOUT_MS) only up to 3200mS. In case the server does not 
>>> respond I receive the exception 
>>> "*com.google.gwt.http.client.RequestTimeoutException: 
>>> A request timeout has expired after 3200 ms*&

Re: Question about setting GWT RPC timeout

[Colin Alworth]

I believe you're experiencing different timeouts in different cases. That 
is, the problem you're facing of a short timeout before you use your 
RPC_TIMEOUT_MS is a server-side timeout (or potentially a proxy?), but 
after you set a client-side timeout, the client is observing that the 
server is taking too long, and terminating the call from its side, 
resulting in the RequestTimeoutException.

To confirm this, try setting the client-side timeout to something like one 
minute, 60_000, and see that the error returns to the old message you were 
seeing. A timeout set like this does not guarantee that the server stops 
processing the request, only that the client stops waiting for it, and it 
may not be appropriate for your use case at all.

With the client-side timeout set to a reasonable amount or entirely 
removed, take a closer look at the error message you're getting from the 
server, and any server or proxy logs you're getting. If there is a proxy, 
see if you can connect directly to the server to rule out the proxy setting 
this short timeout. Very likely this is a configuration on the server/proxy 
that can be change to suit your requirements.

On Thursday, April 6, 2023 at 2:26:31 AM UTC-5 Dmitri wrote:

> Dear gurus,
>
> I'm learning Java and GWT and I'm facing a problem with setting timeout 
> for PRC calls. I want to extend the RPC timeout before the client reports a 
> failure. The code I'm using is attached below.
>
> I'm running a client in firefox and experience the following problem:
>
> I want to achieve a timeout of 20-30 seconds. However I can set the 
> timeout (RPC_TIMEOUT_MS) only up to 3200mS. In case the server does not 
> respond I receive the exception 
> "*com.google.gwt.http.client.RequestTimeoutException: 
> A request timeout has expired after 3200 ms*" accurately after defined 
> time.
>
> However in case set timeout exceeds the 3300ms of above the exception is 
> different "*com.google.gwt.user.client.rpc.StatusCodeException: 0*" and 
> is thrown always after 3-4 seconds.
>
> What causes this exception and how can I extend the waiting time?
>
> Thank you,
> Best regards
> Dmitri
>
> The code:
> public class MyClass implements EntryPoint {
>
>   private static final int RPC_TIMEOUT_MS = 3300;
>
>   private static class TimeoutRequestBuilder extends RpcRequestBuilder {
> @Override
> protected RequestBuilder doCreate(String serviceEntryPoint) {
>   RequestBuilder builder = super.doCreate(serviceEntryPoint);
>   builder.setTimeoutMillis(RPC_TIMEOUT_MS);
>   return builder;
> }
>   }
>
>   private static final RpcRequestBuilder requestBuilder = new 
> TimeoutRequestBuilder();
>   private final HubServiceAsync myService = GWT.create(HubService.class);
>
>   @Override
>   public void onModuleLoad() {
> ((ServiceDefTarget) hmyService).setRpcRequestBuilder(requestBuilder);
>
> final MainView mainView = new MainView(hubService);
>
> RootPanel rootPanel = RootPanel.get();
> rootPanel.add(mainView);
>
> Window.addResizeHandler(new ResizeHandler() {
>   @Override
>   public void onResize(ResizeEvent event) {
> mainView.resize();
>   }
> });
>   }
> }
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/76443417-083f-4401-94f5-cd9fd392f80fn%40googlegroups.com.

[gwt-contrib] Re: Compiling gwt on Mac ?

[Colin Alworth]

That patch is delayed since it turns out there are some tests that rely on 
specific behavior from the JVM - a few JPMS violations in legacy dev mode, 
and apparently Annotation.toString() changed slightly breaking a few other 
tests. I think it is just about ready, but each round of testing takes a 
few hours, so it is hard to get it done in one sitting.

But it will produce working output, including docs, if you want to use it 
to build a GWT SDK locally.

On Wednesday, March 22, 2023 at 4:25:48 AM UTC-5 Jens wrote:

> Doctool hasn't been updated yet, see: 
> https://github.com/gwtproject/gwt/pull/9780
>
> You can install Java 8 for Mac x86 using 
> https://adoptium.net/de/temurin/releases/?version=8 
>
> If you use a Mac with Apple Silicon and don't want to install Rosetta 2 
> you would need to install Java 8 from a different vendor, e.g. Azul Zulu or 
> Amazon Corretto 8 (also available via brew.sh). Or you make/use a Docker 
> image with Java 8 + ANT (+ Maven if you want to push the build to a 
> corporate repository), mount the GWT SDK + Tools repositories and compile 
> inside the container.
>
> -- J.
>
> stuckagain schrieb am Mittwoch, 22. März 2023 um 09:21:42 UTC+1:
>
>> Is it possible to compile GWT on a Mac ? Is it mandatory to use Java 8, 
>> that version is no longer available.
>>
>> I have Java 11 installed, but I get the following error:
>>
>>
>>
>> compile:
>>
>> [mkdir] Created dir: 
>> /Users/me/Projects/gwt/build/out/build_tools/doctool/bin
>>
>> [javac] Compiling 10 source files to 
>> /Users/me/Projects/gwt/build/out/build_tools/doctool/bin
>>
>> [javac] -Xbootclasspath/p is no longer a supported option.
>>
>> [javac] Error: Could not create the Java Virtual Machine.
>>
>> [javac] Error: A fatal exception has occurred. Program will exit.
>>
>>
>>
>>

-- 
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/a72e40cb-8dd4-4e20-be09-5739020c8c55n%40googlegroups.com.

Re: Eclpse GWT 3.0 plugin not available

[Colin Alworth]

Error scanning file GWT29_JDK11.class
at 
org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:708)

This error should be fixed with GWT 2.10.0, or by disabling the 
annotation-based servlet configurations. A very similar issue is discussed 
at https://github.com/gwtproject/gwt/issues/9606.

Alternatively, strongly consider dividing client and server classpaths, and 
only using DevMode (or better, CodeServer) to serve your GWT client 
content, and use your intended servlet container for server code. Doing so 
will avoid this and many other issues, which stem from the Jetty in dev 
mode being configured and updated for the purposes of DevMode first and 
foremost.
On Tuesday, February 7, 2023 at 4:32:08 PM UTC-6 hprc wrote:

> no
>
> I have confirmed that it works only with Java8 + GWT sdk 2.8 or 2.9.
>
> When using JDK17, the following error is displayed.
> It's been discussed in the thread, but I think it's probably a problem 
> with Jetty's JDK support.
> I don't understand the details.
>
> The stack trace is shown below.
>
> *
> Running CodeServer with parameters: [-noprecompile, -port, 9876, 
> -sourceLevel, 1.8, -bindAddress, 127.0.0.1, -launcherDir, 
> C:\pleiades-2022-12-java-win-64bit-jre_20230124\workspace\GWT29_JDK11\war, 
> -logLevel, INFO, -style, OBFUSCATED, kut.hp_rc.GWT29_JDK11]
> Super Dev Mode starting up
>workDir: 
> C:\Users\kazuo\AppData\Local\Temp\gwt-codeserver-7013139281438506203.tmp
> 2023-02-08 07:28:33.263:INFO::main: Logging initialized @2024ms
>Loading Java files in kut.hp_rc.GWT29_JDK11.
>Module setup completed in 2803 ms
> 2023-02-08 07:28:35.350:INFO:oejs.Server:main: jetty-9.2.z-SNAPSHOT
> 2023-02-08 07:28:35.373:INFO:oejsh.ContextHandler:main: Started 
> o.e.j.s.ServletContextHandler@7bbec1cc{/,null,AVAILABLE}
> 2023-02-08 07:28:35.408:INFO:oejs.ServerConnector:main: Started 
> ServerConnector@5324647{HTTP/1.1}{127.0.0.1:9876}
> 2023-02-08 07:28:35.408:INFO:oejs.Server:main: Started @4170ms
>
> The code server is ready at http://127.0.0.1:9876/
> Code server started in 3.106 s ms
> [ERROR] jreLeakPrevention.gcDaemonFail
> java.lang.ClassNotFoundException: sun.misc.GC
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
> at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:315)
> at 
> com.google.gwt.dev.shell.jetty.JettyLauncher.jreLeakPrevention(JettyLauncher.java:899)
> at 
> com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:722)
> at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:636)
> at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:898)
> at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:705)
> at com.google.gwt.dev.DevMode.main(DevMode.java:432)
> 2023-02-08 07:28:35.606:INFO:oejs.Server:main: jetty-9.2.z-SNAPSHOT
> Starting Jetty on port 
>[WARN] Failed startup of context 
> c.g.g.d.s.j.WebAppContextWithReload@65d26881{/,file:/C:/pleiades-2022-12-java-win-64bit-jre_20230124/workspace/GWT29_JDK11/war/,STARTING}{C:\pleiades-2022-12-java-win-64bit-jre_20230124\workspace\GWT29_JDK11\war}
> MultiException[java.lang.RuntimeException: Error scanning file 
> GWT29_JDK11$1.class, java.lang.RuntimeException: Error scanning file 
> GWT29_JDK11$1MyHandler$1.class, java.lang.RuntimeException: Error scanning 
> file GWT29_JDK11$1MyHandler.class, java.lang.RuntimeException: Error 
> scanning file GWT29_JDK11.class]
> at 
> org.eclipse.jetty.annotations.AnnotationConfiguration.scanForAnnotations(AnnotationConfiguration.java:536)
> at 
> org.eclipse.jetty.annotations.AnnotationConfiguration.configure(AnnotationConfiguration.java:447)
> at 
> org.eclipse.jetty.webapp.WebAppContext.configure(WebAppContext.java:479)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1337)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> at 
> com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(JettyLauncher.java:550)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> at 
> org.eclipse.jetty.server.handler.RequestLogHandler.doStart(RequestLogHandler.java:140)
> at 

[gwt-contrib] Re: New home for GWT Eclipse Plugin

[Colin Alworth]

The marketplace entry is updated, and is using the 4.0.0 release at 
plugins.gwtproject.org. There is a subdirectory that lists all deployed 
versions, including a nightly build - each of these directories can be 
added directly to eclipse as an update site: 
https://plugins.gwtproject.org/eclipse/gwt-eclipse-plugin/.

This deployment is managed presently by 
https://github.com/Vertispan/gwtproject.org. 

On Friday, February 3, 2023 at 1:39:10 PM UTC-6 Jens wrote:

> Seems fine to use the gwtproject.org domain for it. I slightly tend 
> towards plugins.gwtproject.org/eclipse because it is slightly more 
> descriptive and then we could also provide 
> plugins.gwtproject.org/browser-extensions to publish the last working 
> classic dev mode browser extensions for people having such an old setup. 
> Currently they are all hosted on google.com domain (see: 
> https://www.gwtproject.org/missing-plugin/) and might disappear at any 
> time.
>
> As there was some trouble getting access to the marketplace maybe in the 
> long run some mechanisms should be put into place to avoid that situation 
> in the future. For example some online password manager with password 
> sharing between trustworthy community members. I appreciate the commitment 
> of Vertispan but there should be a backup plan in case something unexpected 
> happens.
>
> -- J.
>
> Colin Alworth schrieb am Samstag, 28. Januar 2023 um 03:45:13 UTC+1:
>
>> The GWT Eclipse Plugin has become unmaintained, and over the last several 
>> months several community members have stepped up to update it to run on 
>> recent Eclipse versions, and support the new GWT groupId.
>>
>> As part of that process, we've created a new marketplace entry, and while 
>> it is still pointed at the old 3.0 release, we're preparing a new release, 
>> and hope to have it out within a week.
>>
>> https://marketplace.eclipse.org/content/gwt-plugin/
>>
>> In order to deploy a new version, we need to deploy the unpacked 
>> repository somewhere - which rules out a maven repository. The footprint of 
>> the unpacked workspace is fairly large, around 350mb, which would be too 
>> big for github pages after three releases. We could still deploy releases 
>> zips, but need somewhere else to put the unpacked content.
>>
>> There is probably another clever solution, but the straightforward 
>> solution seems to be to add a subdomain on gwtproject.org and unpack the 
>> content there - I propose eclipse.gwtproject.org. As we did for 
>> www.gwtproject.org and samples.gwtproject.org, I've put an example of 
>> this at eclipse.gwtproject.org.vertispan.com, and deployed a single 
>> snapshot of the 4.0 plugin (note that as with many eclipse plugin repos, 
>> this doesn't load correctly in a browser):
>> https://eclipse.gwtproject.org.vertispan.com/2023-01-18/
>>
>> If there are no objections, once we've finished the 4.0 plugin and are 
>> ready for a release, I'll formally set up *eclipse.gwtproject.org 
>> <http://eclipse.gwtproject.org>*. For the moment I anticipate only a 
>> plugins/ directory, with each versioned release (and maybe a nightly build 
>> setup too), to allow for additional content later.
>>
>> Using the gwtproject.org domain name seems natural as a large number of 
>> GWT developers use Eclipse and this plugin, and the documentation at 
>> gwtproject.org has long since offered Eclipse instructions, with little 
>> space given to IntelliJ or Maven/Gradle. I'd further propose we should 
>> improve that situation, but that's a separate discussion. Vertispan intends 
>> to host this new plugin content, and we are already hosting the 
>> gwtproject.org domain content.
>>
>> If there are reservations about gwtproject.org also hosting the eclipse 
>> plugin, we can set up an alternate domain name for this work, though at 
>> least for the time being, Vertspan will be hosting these together.
>>
>

-- 
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/5a849455-6192-48aa-8c4d-cb724ebc120bn%40googlegroups.com.

[gwt-contrib] New home for GWT Eclipse Plugin

[Colin Alworth]

The GWT Eclipse Plugin has become unmaintained, and over the last several 
months several community members have stepped up to update it to run on 
recent Eclipse versions, and support the new GWT groupId.

As part of that process, we've created a new marketplace entry, and while 
it is still pointed at the old 3.0 release, we're preparing a new release, 
and hope to have it out within a week.

https://marketplace.eclipse.org/content/gwt-plugin/

In order to deploy a new version, we need to deploy the unpacked repository 
somewhere - which rules out a maven repository. The footprint of the 
unpacked workspace is fairly large, around 350mb, which would be too big 
for github pages after three releases. We could still deploy releases zips, 
but need somewhere else to put the unpacked content.

There is probably another clever solution, but the straightforward solution 
seems to be to add a subdomain on gwtproject.org and unpack the content 
there - I propose eclipse.gwtproject.org. As we did for www.gwtproject.org 
and samples.gwtproject.org, I've put an example of this at 
eclipse.gwtproject.org.vertispan.com, and deployed a single snapshot of the 
4.0 plugin (note that as with many eclipse plugin repos, this doesn't load 
correctly in a browser):
https://eclipse.gwtproject.org.vertispan.com/2023-01-18/

If there are no objections, once we've finished the 4.0 plugin and are 
ready for a release, I'll formally set up *eclipse.gwtproject.org*. For the 
moment I anticipate only a plugins/ directory, with each versioned release 
(and maybe a nightly build setup too), to allow for additional content 
later.

Using the gwtproject.org domain name seems natural as a large number of GWT 
developers use Eclipse and this plugin, and the documentation at 
gwtproject.org has long since offered Eclipse instructions, with little 
space given to IntelliJ or Maven/Gradle. I'd further propose we should 
improve that situation, but that's a separate discussion. Vertispan intends 
to host this new plugin content, and we are already hosting the 
gwtproject.org domain content.

If there are reservations about gwtproject.org also hosting the eclipse 
plugin, we can set up an alternate domain name for this work, though at 
least for the time being, Vertspan will be hosting these together.

-- 
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/66c5f0b1-5c33-4f43-8cb5-df97d8ca11adn%40googlegroups.com.

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

[Colin Alworth]

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 

Re: Security Vulnerabilities with GWT

[Colin Alworth]

Thanks for working on this, Rafat.

I've deployed a build of this to https://repo.vertispan.com/gwt-snapshot/ 
with version 2.11.0-fix-9778-SNAPSHOT. This uses the new groupIds, 
org.gwtproject:gwt-servlet:2.11.0-fix-9778-SNAPSHOT.

For example, see 
https://repo.vertispan.com/gwt-snapshot/org/gwtproject/gwt-servlet/2.11.0-fix-9778-SNAPSHOT/
 
to get the gwt-servlet jar.

The patch looks like what I had expected from earlier discussion, thanks 
for manually confirming it yourself. If someone can confirm the build 
solves this issue, we can move forward with landing it.
On Friday, November 11, 2022 at 2:14:20 PM UTC-6 rafat.a...@gmail.com wrote:

> I did make a PR for fixing this issue by removing the pom.xml file from 
> the rebased jar https://github.com/gwtproject/gwt/pull/9785
>
> I did scan a sample project and attached is the report. It would be great 
> if there is anyone can help verify the fix.
> 
> On Friday, 28 October 2022 at 16:53:20 UTC+2 nilo...@gmail.com wrote:
>
>> This is discussed at https://github.com/gwtproject/gwt/issues/9778 and 
>> https://github.com/gwtproject/gwt/issues/9752: this is a false positive, 
>> but still needs to be corrected. The simplest fix is probably to just stop 
>> packaging up the "I am running an old version" marker file, since the 
>>
>> Is there a functioning "bug bounty" tool for github? I found a few 
>> options that all seem defunct, but this seems like a good candidate for 
>> someone to either scratch their own itch and get it fixed, or fund someone 
>> else who has the time.
>>
>> Regardless, as someone not actually affected by this false positive (so I 
>> can't justify the time right now to focus on it, run the verification that 
>> tools accept the output, etc), I'll put up a bounty of 100USD (via 
>> paypal/etc) to see this fixed, with a bonus 100USD for a first-time 
>> contributor. If someone has experience with a platform for setting up 
>> bounties like this, it might be helpful to formalize future issues.
>>
>> On Wednesday, October 26, 2022 at 4:07:48 PM UTC-5 bsha...@qvera.com 
>> wrote:
>>
>>> I know that this conversation is about 2 years old.  We upgraded to GWT 
>>> 2.10 in hopes that it would resolve the following vulnerabilities with 
>>> protobuf-java, they are all being reports in the gwt-servlet.jar (version 
>>> 2.10.0):
>>> https://nvd.nist.gov/vuln/detail/CVE-2022-3171
>>> https://www.cve.org/CVERecord?id=CVE-2015-5237
>>> https://github.com/advisories/GHSA-wrvw-hg22-4m67
>>> https://github.com/advisories/GHSA-h4h5-3hr4-j3g2
>>> https://nvd.nist.gov/vuln/detail/CVE-2021-22569
>>>
>>> These are all being reported in our project by the AWS Enhanced 
>>> Scanning.  It there any way to upgrade Protobuf from 2.5.0 to the latest 
>>> version of 3.21.8?
>>>
>>> Thanks in advance.
>>> Ben
>>>
>>> On Tuesday, June 30, 2020 at 4:16:01 AM UTC-6 priyako...@gmail.com 
>>> wrote:
>>>
 Thank you very much for quick responses.
 Here are Vulnerabilities listed -


 Gwt-dev.jar -
 1.1 Vulnerable version of jetty library(current version-- 9.2.14, 
 available version -9.2.27+ ) 
 [Associated CVEs -  
 CVE-2017-7656,CVE-2017-7657,CVE-2017-7658,CVE-2017-9735,CVE-2018-12536]
 1.2 Vulnerable version of commons-collections(current version - 3.2.1)  
 [ CVE-2015-6420,CVE-2017-15708,CVE-2014-3577]
 1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current 
 version - 4.3.1)  [ CVE-2015-6420,CVE-2017-15708,CVE-2014-3577]
 1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, 
 available version - 3.4.0) [CVE-2015-5237]
 1.5  Vulnerable version of htmlunit ( current version - 2.19 , 
 available version- 2.37) [CVE-2020-5529]

 Gwt-servlet.jar -
 1.1 Vulnerable version of Google Protobuf(current version - 
 2.5.0, available version - 3.4.0) [CVE-2015-5237]


 On Monday, 29 June 2020 16:27:41 UTC+5:30, Priya Kolekar wrote:
>
>
> Hi All,
>
> Security Vulnerability have been detected in gwt-dev.jar & 
> gwt-servlet.jar(in release 2.8.2) & are reported by Dependency checker 
> tool .
>
> Below are the details -
>
> Gwt-dev.jar -
> 1.1 Vulnerable version of jetty library(current version-- 9.2.14, 
> available version -9.2.27+ )
> 1.2 Vulnerable version of commons-collections(current version - 3.2.1)
> 1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current 
> version - 4.3.1)
> 1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, 
> available version - 3.4.0)
> 1.5  Vulnerable version of htmlunit ( current version - 2.19 , 
> available version- 2.37)
>
> Gwt-servlet.jar -
> 1.1 Vulnerable version of Google Protobuf(current version - 
> 2.5.0, available version - 3.4.0)
>
> Given above vulnerabilities -
> 

Re: Security Vulnerabilities with GWT

[Colin Alworth]

This is discussed at https://github.com/gwtproject/gwt/issues/9778 and 
https://github.com/gwtproject/gwt/issues/9752: this is a false positive, 
but still needs to be corrected. The simplest fix is probably to just stop 
packaging up the "I am running an old version" marker file, since the 

Is there a functioning "bug bounty" tool for github? I found a few options 
that all seem defunct, but this seems like a good candidate for someone to 
either scratch their own itch and get it fixed, or fund someone else who 
has the time.

Regardless, as someone not actually affected by this false positive (so I 
can't justify the time right now to focus on it, run the verification that 
tools accept the output, etc), I'll put up a bounty of 100USD (via 
paypal/etc) to see this fixed, with a bonus 100USD for a first-time 
contributor. If someone has experience with a platform for setting up 
bounties like this, it might be helpful to formalize future issues.

On Wednesday, October 26, 2022 at 4:07:48 PM UTC-5 bsha...@qvera.com wrote:

> I know that this conversation is about 2 years old.  We upgraded to GWT 
> 2.10 in hopes that it would resolve the following vulnerabilities with 
> protobuf-java, they are all being reports in the gwt-servlet.jar (version 
> 2.10.0):
> https://nvd.nist.gov/vuln/detail/CVE-2022-3171
> https://www.cve.org/CVERecord?id=CVE-2015-5237
> https://github.com/advisories/GHSA-wrvw-hg22-4m67
> https://github.com/advisories/GHSA-h4h5-3hr4-j3g2
> https://nvd.nist.gov/vuln/detail/CVE-2021-22569
>
> These are all being reported in our project by the AWS Enhanced Scanning.  
> It there any way to upgrade Protobuf from 2.5.0 to the latest version of 
> 3.21.8?
>
> Thanks in advance.
> Ben
>
> On Tuesday, June 30, 2020 at 4:16:01 AM UTC-6 priyako...@gmail.com wrote:
>
>> Thank you very much for quick responses.
>> Here are Vulnerabilities listed -
>>
>>
>> Gwt-dev.jar -
>> 1.1 Vulnerable version of jetty library(current version-- 9.2.14, 
>> available version -9.2.27+ ) 
>> [Associated CVEs -  
>> CVE-2017-7656,CVE-2017-7657,CVE-2017-7658,CVE-2017-9735,CVE-2018-12536]
>> 1.2 Vulnerable version of commons-collections(current version - 3.2.1)  [ 
>> CVE-2015-6420,CVE-2017-15708,CVE-2014-3577]
>> 1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current 
>> version - 4.3.1)  [ CVE-2015-6420,CVE-2017-15708,CVE-2014-3577]
>> 1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, 
>> available version - 3.4.0) [CVE-2015-5237]
>> 1.5  Vulnerable version of htmlunit ( current version - 2.19 , available 
>> version- 2.37) [CVE-2020-5529]
>>
>> Gwt-servlet.jar -
>> 1.1 Vulnerable version of Google Protobuf(current version - 
>> 2.5.0, available version - 3.4.0) [CVE-2015-5237]
>>
>>
>> On Monday, 29 June 2020 16:27:41 UTC+5:30, Priya Kolekar wrote:
>>>
>>>
>>> Hi All,
>>>
>>> Security Vulnerability have been detected in gwt-dev.jar & 
>>> gwt-servlet.jar(in release 2.8.2) & are reported by Dependency checker 
>>> tool .
>>>
>>> Below are the details -
>>>
>>> Gwt-dev.jar -
>>> 1.1 Vulnerable version of jetty library(current version-- 9.2.14, 
>>> available version -9.2.27+ )
>>> 1.2 Vulnerable version of commons-collections(current version - 3.2.1)
>>> 1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current 
>>> version - 4.3.1)
>>> 1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, 
>>> available version - 3.4.0)
>>> 1.5  Vulnerable version of htmlunit ( current version - 2.19 , available 
>>> version- 2.37)
>>>
>>> Gwt-servlet.jar -
>>> 1.1 Vulnerable version of Google Protobuf(current version - 
>>> 2.5.0, available version - 3.4.0)
>>>
>>> Given above vulnerabilities -
>>> 1. Are those security issues addressed in latest 2.9.0 release?
>>> 2. If no, is there a plan to include them in any future release say 3.x?
>>> 3. As we know that gwt-dev.jar is used for development purpose & can be 
>>> flagged as false positive, still are there any attack surfaces exists?
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/1bdbe148-b8c7-41a8-bbdc-90d0dfb0ffedn%40googlegroups.com.

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

Re: GWT 2.10.0: gradle gwtSuperDev - java.lang.IllegalArgumentException: No selectors

[Colin Alworth]

My apologies, I didn't notice your attachment until I had already hit send. 
Checking the list shows that gwt-materialdesign is bringing in an old 
version of htmlunit (GWT 2.10.0 updated this also), which is in turn 
bringing in some old jetty versions:
||\--- org.eclipse.jetty.websocket:websocket-client:9.2.18.v20160721
|| +--- org.eclipse.jetty:jetty-util:9.2.18.v20160721
*|| +--- org.eclipse.jetty:jetty-io:9.2.18.v20160721*

I can't speak to how your Gradle setup is configured, but I think you 
should have an explicit compile dependency on gwt-dev:2.10.0, which should 
at least force jetty-io and htmlunit to be updated to the expected versions.


On Tuesday, August 9, 2022 at 1:58:04 PM UTC-5 Colin Alworth wrote:

> Your stack trace lines up except for the top frame - jetty-io 
> 9.4.4.v20210927 has a blank line for SelectorManager.java:81, and the 
> source for the file at that version doesn't contain the string "No 
> selectors". On the other hand, jetty-io 9.2.14.v20151116 has this as a 
> constructor (and line 81 is where it throws):
> protected SelectorManager(Executor executor, Scheduler scheduler, int 
> selectors)
> {
> if (selectors<=0)
> throw new IllegalArgumentException("No selectors");
> this.executor = executor;
> this.scheduler = scheduler;
> _selectors = new ManagedSelector[selectors];
> }
>
> This much older version of jetty-io is the general version of Jetty that 
> GWT 2.9 used (as well as a few earlier GWT versions).
>
> My guess is that you have correctly updated GWT, and the expected version 
> of Jetty has been updated (9.4.44), except somehow you have a dependency on 
> the old version of jetty-io. Check the rest of your classpath, or the 
> particular gradle plugin you are using?
>
>
> On Tuesday, August 9, 2022 at 9:20:42 AM UTC-5 Michael Joyner wrote:
>
>> Meh,
>>
>> I've managed to break my GWT setup again. This time for superdev mode. 
>> Looking for suggestions on where the (I assume) Jetty conflict is coming 
>> from.
>>
>> Getting the following stacktrace after "Module setup completed" is logged 
>> when trying to run "./gradlew subproject:gwtSuperDev"
>>
>> java.lang.IllegalArgumentException: No selectors
>> at 
>> org.eclipse.jetty.io.SelectorManager.(SelectorManager.java:81)
>> at 
>> org.eclipse.jetty.server.ServerConnector$ServerConnectorManager.(ServerConnector.java:600)
>> at 
>> org.eclipse.jetty.server.ServerConnector.newSelectorManager(ServerConnector.java:223)
>> at 
>> org.eclipse.jetty.server.ServerConnector.(ServerConnector.java:216)
>> at 
>> org.eclipse.jetty.server.ServerConnector.(ServerConnector.java:98)
>> at 
>> com.google.gwt.dev.codeserver.WebServer.start(WebServer.java:122)
>> at 
>> com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:162)
>> at 
>> com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:104)
>> at 
>> com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:55)
>>
>>
>> We are using Gradle with the wisepersist GWT plugin:
>>
>> id "org.wisepersist.gwt" version "1.1.18"id "org.gretty" version "3.0.8"
>>
>> gwt {
>>
>> gwtVersion = "2.10.0"src += 
>> files(compileJava.options.annotationProcessorGeneratedSourcesDirectory)
>> logLevel = "INFO"maxHeapSize = "2048M";
>> modules 'com.newsrx.butter.Butter'compiler {
>> disableClassMetadata = false;
>> strict = true;
>> style = "OBF";
>> }// allow sdm on simultaneous modules//devModules 
>> 'com.newsrx.butter.Butter', 'com.newsrx.newsletter.NewsletterBrowser', 
>> 'com.newsrx.dailies.DailiesBrowser'superDev {noPrecompile = 
>> false;
>> failOnError = false;
>> bindAddress = "0.0.0.0";
>> }}
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/779a80e9-9313-4377-b561-4ab5654394bcn%40googlegroups.com.

Re: GWT 2.10.0: gradle gwtSuperDev - java.lang.IllegalArgumentException: No selectors

[Colin Alworth]

Your stack trace lines up except for the top frame - jetty-io 
9.4.4.v20210927 has a blank line for SelectorManager.java:81, and the 
source for the file at that version doesn't contain the string "No 
selectors". On the other hand, jetty-io 9.2.14.v20151116 has this as a 
constructor (and line 81 is where it throws):
protected SelectorManager(Executor executor, Scheduler scheduler, int 
selectors)
{
if (selectors<=0)
throw new IllegalArgumentException("No selectors");
this.executor = executor;
this.scheduler = scheduler;
_selectors = new ManagedSelector[selectors];
}

This much older version of jetty-io is the general version of Jetty that 
GWT 2.9 used (as well as a few earlier GWT versions).

My guess is that you have correctly updated GWT, and the expected version 
of Jetty has been updated (9.4.44), except somehow you have a dependency on 
the old version of jetty-io. Check the rest of your classpath, or the 
particular gradle plugin you are using?


On Tuesday, August 9, 2022 at 9:20:42 AM UTC-5 Michael Joyner wrote:

> Meh,
>
> I've managed to break my GWT setup again. This time for superdev mode. 
> Looking for suggestions on where the (I assume) Jetty conflict is coming 
> from.
>
> Getting the following stacktrace after "Module setup completed" is logged 
> when trying to run "./gradlew subproject:gwtSuperDev"
>
> java.lang.IllegalArgumentException: No selectors
> at 
> org.eclipse.jetty.io.SelectorManager.(SelectorManager.java:81)
> at 
> org.eclipse.jetty.server.ServerConnector$ServerConnectorManager.(ServerConnector.java:600)
> at 
> org.eclipse.jetty.server.ServerConnector.newSelectorManager(ServerConnector.java:223)
> at 
> org.eclipse.jetty.server.ServerConnector.(ServerConnector.java:216)
> at 
> org.eclipse.jetty.server.ServerConnector.(ServerConnector.java:98)
> at 
> com.google.gwt.dev.codeserver.WebServer.start(WebServer.java:122)
> at 
> com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:162)
> at 
> com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:104)
> at 
> com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:55)
>
>
> We are using Gradle with the wisepersist GWT plugin:
>
> id "org.wisepersist.gwt" version "1.1.18"id "org.gretty" version "3.0.8"
>
> gwt {
>
> gwtVersion = "2.10.0"src += 
> files(compileJava.options.annotationProcessorGeneratedSourcesDirectory)
> logLevel = "INFO"maxHeapSize = "2048M";
> modules 'com.newsrx.butter.Butter'compiler {
> disableClassMetadata = false;
> strict = true;
> style = "OBF";
> }// allow sdm on simultaneous modules//devModules 
> 'com.newsrx.butter.Butter', 'com.newsrx.newsletter.NewsletterBrowser', 
> 'com.newsrx.dailies.DailiesBrowser'superDev {noPrecompile = false;
> failOnError = false;
> bindAddress = "0.0.0.0";
> }}
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/f0314d8f-d70e-4244-a421-1709cd6efcdfn%40googlegroups.com.

[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 

Re: http://localhost:8080/....../gemsInquiry/gemsInquiry.nocaches.js 404 (Not Found)

[Colin Alworth]

Can you share how you are starting GWT to debug this, and what the logs 
show?

You should not need (or want) both gwt-maven-plugins in your pom.xml.

On Thursday, July 28, 2022 at 8:02:44 AM UTC-5 parthib...@gmail.com wrote:

> Hi Everyone,
>  I am using *Java 17* and *GWT 2.10.0* when trying to start 
> application through GWT plugin in IntelliJ. I am facing below error.
>
>
> * src="../gemsInquiry/gemsInquiry.nocache.js">*
>  
> *GET http://localhost:8080//gemsInquiry/gemsInquiry.nocaches.js 
>  404 (Not 
> Found)*
>
> gemsInquiry.nocaches.js file not generated so I am facing 404 ERROR
>
> *GemsInquiry.gwt.xml*
>
> 
> 
>
> 
> 
> 
>
> 
> 
>
> 
>  
> 
>
>
> *pom.xml*
>
> 
> org.gwtproject
> gwt-servlet
> 2.10.0
> runtime
> 
>
> 
> org.gwtproject
> gwt-user
> 2.10.0
> provided
> 
>
> 
> org.gwtproject
> gwt-dev
> 2.10.0
> provided
> 
>
>
>
> 
> net.ltgt.gwt.maven
> gwt-maven-plugin
> 1.0.1
> true
> 
> comreport.client.service
> true
> ${project.build.outputDirectory}
>
> ${project.basedir}/src/main/resources/com/../gems/GemsInquiry.gwt.xml
> ${project.build.directory}/gwt/extra
> 
> -gen
> 
>
> ${project.basedir}/../../target/..${finalNameVersion}${extn}/alliance-web-app-${project.parent.version}
> 
> 
>
> ${project.build.directory}/gwt/extra
> 
> 
>
> 
> org.codehaus.mojo
> gwt-maven-plugin
> 2.10.0
> 
> JS
> 
> 
>
>
>
> Regards,
> Parthiban Chelladurai
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/e2233869-1bd1-428d-a616-fe7d5f992056n%40googlegroups.com.

Re: Old system in GWT 1.4.61

[Colin Alworth]

There is no explicit "Chrome" support in GWT - Chrome started its life as 
another browser based around the WebKit engine. This is referred to in GWT 
as "safari", though WebKit started its life as part of the Konqueror 
browser, which pre-dates Safari's use of it (though arguably Safari 
popularized it).

Oddly, GWT 1.4.61 isn't even listed on 
https://www.gwtproject.org/release-notes.html, but your build is probably 
from about Aug 2007. According to Wikipedia, Chrome was first released in 
September 2008, and the last GWT 1.x release was made in September 2009, as 
GWT 1.7.1 (see 
https://www.gwtproject.org/release-notes.html#Release_Notes_1_7_1). If the 
issue is merely that there are some specific changes in the Chrome product 
(as opposed to Safari) that need minimal updates, that might be enough, and 
should be a very small change to your project (while still requiring an 
ancient version of Java, and platform-specific code to debug). The release 
notes should help in understanding what changes might be necessary.

With that said, I would be very surprised if the issue is simply that 
Chrome isn't supported by old versions of GWT, but more likely that some 
change happened in the last 15 years since GWT 1.4.61. Very likely GWT had 
the fix before Chrome introduced the breaking change, but without specifics 
of the actual issue you are facing, I couldn't guess further.

Can you give some specifics about what is not working, what error, logs, 
and behavior you are seeing? Have you tried updating as far as GWT 1.7 or 
some other early 2.x release to see if a simple update can keep your 
project building but still resolve this?



On Monday, July 25, 2022 at 10:50:45 AM UTC-5 marian...@gmail.com wrote:

> Hi Guys
>
> got an old system running in 1.4.61 that won't work in chrome.
>
> This is a very complicated and old system that no one really knows about.
>
> I am trying to do the minimum changes to get it to work with chrome.
>
> Obvisouly the newer the GWT, the more breaking changes potentially 
> introduced plus the backend will require java upgrade, so it will trigger a 
> number of changes that I do not want to do, due to the reasons above.
>
> Anyone knows when GWT first started supporting chrome?
>
> thanks
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/724f5345-039b-480e-8560-e1ed0c70d527n%40googlegroups.com.

GWT 2.10.0 release

[Colin Alworth]

I'm very happy to announce the release of GWT 2.10.0. This is the first 
release using our new groupId, org.gwtproject, and the final release using 
com.google.gwt. If you resolve dependencies from Maven Central, please be 
certain that your project is using com.google.gwt:gwt (or 
org.gwtproject:gwt) as a BOM, so that you are certain to have consistent 
versions of gwt-user and gwt-dev, even across groupIds.

For this release, either groupId will work, but future releases will only 
be made on the org.gwtproject groupId.

The zip download of the GWT SDK is available at 
https://github.com/gwtproject/gwt/releases/download/2.10.0/gwt-2.10.0.zip

--

Release notes for GWT 2.10.0, taken from 
https://www.gwtproject.org/release-notes.html#Release_Notes_2_10_0

Highlights 
   
   - 
   
   Updated to HtmlUnit 2.55.0 and Jetty 9.4.44. With this newer HtmlUnit 
   build comes support for Promise in unit tests, and the browser strings that 
   can be specified when running tests are “FF”, “Chrome”, “IE” (for IE11), 
   “Edge”, and “Safari”.
   - 
   
   Tested support for running on Java 17, dropped remaining support for 
   running on Java 7.
   - 
   
   Maven groupId is formally changed to org.gwtproject, projects should 
   take care to make sure they are using either the old com.google.gwt:gwt 
   BOM or the new org.gwtproject:gwt BOM to sure that Maven or Gradle 
   correctly handle this change. This will be the last published version using 
   the com.google.gwt groupId.
   - 
   
   Dropped support for IE 8, 9, and 10.
   
Bug fixes 
   
   - Correct Long.hashCode semantics
   - Support CLASSPATH environment variable when creating child processes, 
   fixing a bug where Windows could fail with a long list of arguments.
   - Use Function.name instead of displayName to support visible method 
   names in Chrome 93+.
   - Allow stack traces to be available in Chrome when loading scripts from 
   a remote origin.

JRE Emulation 
   
   - Added OutputStreamWriter emulation.
   - Support StringReader mark() and reset() methods.
   - Added StrictMath emulation.
   - Added BufferedWriter emulation.
   - Added incomplete PrintStream emulation.
   - Add Charset.defaultCharset() emulation.
   - Improve BigInteger emulated performance.
   - System.nanoTime() emulation with performance.now().
   - Added Optional.isEmpty emulation.
   - JRE Emulation improvements/simplifications to facilitate J2CL’s WASM 
   support. Note that these do not always offer specific improvements to GWT 
   itself, but helps to keep the codebases consistent.

Miscellaneous 
   
   - Add support to compile GWT itself in Java 9+.
   - Improve compiled code size for applications that never use streams, by 
   avoiding referencing streams from Throwable.

For more detail, see the commit log 
.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/57e69cc0-3aa5-4252-90d1-9c49077440ban%40googlegroups.com.

[gwt-contrib] Re: Testing for GWT 2.10.0 release

[Colin Alworth]

The last step of the release process is under way, Google's 2.10.0 release 
is underway, we're just waiting for the release to be performed and 
synchronized to Maven Central. When that has finished we can formally 
announce the release.

I've created an issue for next steps to finish our transition to GitHub at 
https://github.com/gwtproject/gwt/issues/9756 and will follow up with a few 
proposed pull requests to make these changes.

Thanks for everyone's support and patience with this process!

On Sunday, May 22, 2022 at 11:00:14 AM UTC-5 mcmi...@gmail.com wrote:

> Hi,
> I could test on Windows 10 (and maybe Windows 11)
> Browser :
> - Firefox
> - Edge (but Chromium only)
> - IE 11 (End of Support on June 15th)
> - Chrome
>
> JVM:
> - 11
> - 17
> - 18
> - 19 eap
> Boris Brudnoy schrieb am Freitag, 20. Mai 2022 um 14:33:02 UTC+2:
>
>> I'll test. I'm on macOS Monterey 12.3.1. Can do whichever JVMs / browsers 
>> run on macOS, which AFAICT is everything but IE11.
>>
>> On Thursday, May 19, 2022 at 11:34:31 PM UTC-4 nilo...@gmail.com wrote:
>>
>>> Hello all,
>>>
>>> All of the preliminary testing that I'm aware of for the upcoming 
>>> release is complete, leaving us with a decent level of confidence in the 
>>> changes. We have a document that outlines the release plan (with a link to 
>>> the standard release steps and the testing process) that has undergone a 
>>> few small tweaks, and I think is ready to go:
>>>
>>> https://docs.google.com/document/d/10Cn0Z7SDv0ZW5OVZdoIdw5EAEDUbtK6vracOOnxj7po/edit
>>>
>>> I'm now asking for volunteers who are able to test the final release 
>>> once it is ready to go. We're hoping for a cross section of testing that 
>>> verifies
>>>
>>>- JVM Version: 8, 11, 17/18
>>>- OS: Linux, OS X, Windows 8.1, 10, 11
>>>- Browser: Chrome, Firefox, Safari, IE11, Edge (blink)
>>>
>>> Windows 8.1 and 10 VMs are available at 
>>> https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/, I'm 
>>> not presently aware of a source for Windows 11 VMs, so ideally we have a 
>>> few people running that natively.
>>>
>>> Please reply to this or contact me off-list (co...@colinalworth.com) 
>>> with the combinations you have access to and are able to test, and we'll 
>>> organize in the next few days, and start the next steps.
>>>
>>> Thanks!
>>>
>>

-- 
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/5df0ff8b-6d48-4c44-a814-3e27cb98427dn%40googlegroups.com.

[gwt-contrib] Testing for GWT 2.10.0 release

[Colin Alworth]

Hello all,

All of the preliminary testing that I'm aware of for the upcoming release 
is complete, leaving us with a decent level of confidence in the changes. 
We have a document that outlines the release plan (with a link to the 
standard release steps and the testing process) that has undergone a few 
small tweaks, and I think is ready to go:
https://docs.google.com/document/d/10Cn0Z7SDv0ZW5OVZdoIdw5EAEDUbtK6vracOOnxj7po/edit

I'm now asking for volunteers who are able to test the final release once 
it is ready to go. We're hoping for a cross section of testing that verifies

   - JVM Version: 8, 11, 17/18
   - OS: Linux, OS X, Windows 8.1, 10, 11
   - Browser: Chrome, Firefox, Safari, IE11, Edge (blink)

Windows 8.1 and 10 VMs are available at 
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/, I'm not 
presently aware of a source for Windows 11 VMs, so ideally we have a few 
people running that natively.

Please reply to this or contact me off-list (co...@colinalworth.com) with 
the combinations you have access to and are able to test, and we'll 
organize in the next few days, and start the next steps.

Thanks!

-- 
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/f28c40dc-796f-426c-92d4-2d14c9178b37n%40googlegroups.com.

Re: [gwt-contrib] Preliminary testing for GWT 2.10 release

[Colin Alworth]

https://gwt-review.googlesource.com/c/gwt/+/23861 is now the only merge 
remaining to cut the release. I just made a few more changes to it, having 
noticed that some maven samples weren't using the new groupId, and in doing 
so I noticed what appeared to be another problem with the new 
org.gwtproject:gwt pom. This is now deployed as version 
2.10.0-new-groupid-4, and should behave just as before, except only 
referencing org.gwtproject groupIds will behave better.


While this needs to be borne out in testing, if everything goes well, 
here's my proposed release process for this unusual release:


   - Get a final +2 for 23861, don't merge it yet.
   - Request that Google disable nightly SNAPSHOT builds, so that we don't 
   produce a build with 23861's changes (see the review for why this is 
   necessary)
   - Merge 23861, cut a release branch, and create a candidate 
   org.gwtproject release for 2.10.0. Note that I'm proposing to _not_ make a 
   RC1 this time, but to move right to the actual GA release. This is for 
   several reasons, mostly to avoid requesting more than one release from 
   Google. The zip download will be made available to testers, and the maven 
   build will be in a (closed) sonatype staging repo to verify it. (A "test" 
   repo will also be created with the com.google.gwt artifacts, so that 
   org.gwtproject:gwt:2.10.0 has its dependencies provided.)
   - Test volunteers will go through the "GWT Smoke Test Checklist", to 
   ensure across our supported platforms we don't have any last moment 
   surprises. This typically takes several days. Note that I’ve reduced the 
   browser/OS permutations, since recent browsers aren’t quite as tied to 
   their OS version as they were in the past.
   - Request that Google perform the com.google.gwt side of the release - 
   only poms will be released.
   - As soon as com.google.gwt is ready to be released, release 
   org.gwtproject 2.10.0 to maven central, and upload the new release zip as a 
   github release. There must be as little gap between these as possible, as 
   each depends on the other, neither release is usable until both are sync'd 
   to central.
   - Finish the release process (tag the release, update release notes, 
   update javadoc).
   - Finish the migration to github (disable the mirror, rename master to 
   main, enable github actions, enable pull requests, enable nightly builds).
   - Request that Google delete the com.google.gwt artifacts from 
   google-snapshots, since they can no longer be updated.

These steps (and a few other links) are in 
https://docs.google.com/document/d/10Cn0Z7SDv0ZW5OVZdoIdw5EAEDUbtK6vracOOnxj7po/edit
 
if you'd like to specifically add comments or suggest changes.

On Tuesday, April 26, 2022 at 6:50:12 AM UTC-5 juan_pablo_gardella wrote:

> After removing an old plexus-utils as suggested at #152 
> <https://github.com/tbroyer/gwt-maven-plugin/issues/152>, I was able to 
> compile and run the application without issues so far. Great work!
>
> On Mon, Apr 25, 2022 at 2:25 PM Freddy Boucher  
> wrote:
>
>> 2.10.0-new-groupid-3 works like a charm (in addition of 
>> net.ltgt.gwt.maven/gwt-maven-plugin 1.0.1)
>> Thanks
>>
>> Le dimanche 24 avril 2022 à 21:34:23 UTC+2, juan_pablo_gardella a écrit :
>>
>>> Tried with Maven 3.8.5 and still fails with same issue. Reported at 
>>> https://github.com/tbroyer/gwt-maven-plugin/issues/152
>>>
>>> On Sun, Apr 24, 2022 at 3:59 PM Colin Alworth  wrote:
>>>
>>>> I've pushed a new build with version 2.10.0-new-groupid-3 that has 
>>>> several @SuppressWarnings("deprecation")s added, and hopefully will solve 
>>>> the WARN logging 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/28cff012-2206-48a8-8882-11b0ea945046n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/28cff012-2206-48a8-8882-11b0ea945046n%40googlegroups.com?utm_medium=email_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-co...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https:/

Re: [gwt-contrib] Preliminary testing for GWT 2.10 release

[Colin Alworth]

I've pushed a new build with version 2.10.0-new-groupid-3 that has several 
@SuppressWarnings("deprecation")s added, and hopefully will solve the WARN 
logging 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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/28cff012-2206-48a8-8882-11b0ea945046n%40googlegroups.com.

Re: [gwt-contrib] Preliminary testing for GWT 2.10 release

[Colin Alworth]

e 918: The method createMuted(DocumentEventRouter super E,E,?>) in the type WaveletBasedSupplement is not applicable for the 
> arguments (DocumentEventRouter)
>  [ERROR] Line 933: The method 
> createPendingNotification(DocumentEventRouter) in the type 
> WaveletBasedSupplement is not applicable for the arguments 
> (DocumentEventRouter)
>  [ERROR] Line 938: The method 
> createWaveletReadState(DocumentEventRouter, 
> ObservablePrimitiveSupplement.Listener) in the type WaveletBasedSupplement 
> is not applicable for the arguments (DocumentEventRouter ?,capture#84-of ? extends N>, ObservablePrimitiveSupplement.Listener)
>  [ERROR] Line 958: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 923: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 913: The method createFolders(DocumentEventRouter super E,E,?>) in the type WaveletBasedSupplement is not applicable for the 
> arguments (DocumentEventRouter)
>  [ERROR] Line 913: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 938: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 933: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 943: The method 
> createWaveletCollapsedState(DocumentEventRouter, 
> ObservablePrimitiveSupplement.Listener) in the type WaveletBasedSupplement 
> is not applicable for the arguments (DocumentEventRouter ?,capture#87-of ? extends N>, ObservablePrimitiveSupplement.Listener)
>  [ERROR] Line 948: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 923: The method createCleared(DocumentEventRouter super E,E,?>) in the type WaveletBasedSupplement is not applicable for the 
> arguments (DocumentEventRouter)
>  [ERROR] Line 958: The method 
> createAbuseStore(DocumentEventRouter) in the type 
> WaveletBasedSupplement is not applicable for the arguments 
> (DocumentEventRouter)
>  [ERROR] Line 953: The method 
> createWaveletNotifiedVersion(DocumentEventRouter) in the 
> type WaveletBasedSupplement is not applicable for the arguments 
> (DocumentEventRouter)
>  [ERROR] Line 918: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 963: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 928: The method 
> create(ObservableMutableDocument) in the type 
> DefaultDocumentEventRouter is not applicable for the arguments 
> (ObservableMutableDocument)
>  [ERROR] Line 963: The method 
> createGadgetStatesDoc(DocumentEventRouter, 
> ObservablePrimitiveSupplement.Listener) in the type WaveletBasedSupplement 
> is not applicable for the arguments (DocumentEventRouter ?,capture#99-of ? extends N>, ObservablePrimitiveSupplement.Listener)
>  [ERROR] Line 928: The method 
> createWaveletArchiveState(DocumentEventRouter) in the type 
> WaveletBasedSupplement is not applicable for the arguments 
> (DocumentEventRouter)
>
>
> On Fri, Apr 22, 2022 at 1:56 AM Colin Alworth  wrote:
>
>> TL;DR: If you have the capability to do so, now would be an excellent 
>> time to help us test GWT in anticipation of a release, especially around 
>> the groupId change we're going to make.
>>
>> --
>>
>> We think that we're one merge away from being ready for a GWT 2.10 
>> release, so I'm starting the release process a bit early, since this last 
>> commit involves changing GWT's groupId away from com.google and to 
>> org.gwtproject.
>>
>> To that end, I have a maven repo with the maven changes along wit all of 
>> the other changes in the GWT 2.10 series. The repo's URL is 
>> https://repo.vertispan.com/gwt-groupid-migration-test/, and the only GWT 
>> version that exists there is "2.10.0-new-groupid-2".
>>
>> Based on earlie

[gwt-contrib] Re: License for gwt-site content

[Colin Alworth]

Ah thank you, I'm very happy to be wrong. I checked a several commits but 
didn't think to look at PRs. 

Changes made to gwt-site do not go through gerrit, but through github since 
late 2014, though the CLA bot does still track it. 

I had already gone through the list of committers who made changes to 
markdown that were more than 5 lines in total and narrowed that list to 
only ones who didn't have a CLA on gwt-review.googlesource.com, but it 
turns out that list of ~38 people must have signed the CLA in some other 
way. I'll recheck the PRs those committers were involved in to confirm, but 
it sounds like we just need to clarify the license directly, since the CLA 
gives us (well, Google technically) the right to do that.

As Google is winding down their direct involvement in the project, the CLA 
bot will be turned off soon, and we'll want to be sure we have an 
explicitly license in all projects that covers contributions, but so far 
this was the only project deficient in this way - and the only project not 
covered by gerrit.

Thanks again for finding my mistake.

On Friday, April 22, 2022 at 3:40:42 AM UTC-5 Jens wrote:

> Haven't all changes been made through gerrit and did require a CLA? 
>
> --J.
>
> Colin Alworth schrieb am Donnerstag, 21. April 2022 um 17:34:49 UTC+2:
>
>> See the question raised at 
>> https://github.com/gwtproject/gwt-site/issues/328.
>>
>> While gwtproject explicitly licenses all "software and sample code" as 
>> under the Apache License 2.0, it appears that we don't have a license 
>> specified for the contents of the gwtproject website (
>> https://gwtproject.org, https://github.com/gwtproject/gwt-site/). A case 
>> could be made that the content is already licensed as under the same 
>> license. It was my understanding that this is discouraged (though at the 
>> moment I'm having a hard time seeing why that would be). I can find 
>> concrete examples of the Apache Foundation licensing their documentation 
>> under the Apache License
>>  * https://github.com/apache/couchdb-documentation
>>  * https://github.com/apache/cordova-docs
>>
>> On the other hand, if the Apache license that applies to all code and 
>> samples does not apply to the contents, then each author owns their own 
>> content directly.
>>
>> I am not a lawyer, but my understanding is that (at least in the country 
>> in which I reside) content is copyrighted by default, and the author owns 
>> that copyright. Additional rights must be granted by the author. If we want 
>> to change the license, we need the approval of the authors so far - 
>> https://github.com/gwtproject/gwt-site/graphs/contributors. Anyone who 
>> doesn't approve would need to have their content removed, if we decide to 
>> change.
>>
>> Are we sufficiently clear that all content is Apache licensed, including 
>> the website documentation? Is there a good reason to consider a different 
>> license instead? Should we seek confirmation from any authors of 
>> substantial amounts of content that their content falls under the license 
>> we choose?
>>
>> My suggestion is to clarify that all content is under the Apache License, 
>> and see a confirmation from any author who wrote more than ~5 lines of 
>> content. If we think we are already clear that all content is under that 
>> license, then we should state that in an up front way, such as setting the 
>> "license" metadata of the gwt-site repo, and adding a LICENSE file.
>>
>> Thoughts, suggestions, pointers to how other projects have handled this?
>>
>

-- 
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/5a00b0b9-fb6b-48c1-a6c9-156908ba3dean%40googlegroups.com.

[gwt-contrib] Preliminary testing for GWT 2.10 release

[Colin Alworth]

TL;DR: If you have the capability to do so, now would be an excellent time 
to help us test GWT in anticipation of a release, especially around the 
groupId change we're going to make.

--

We think that we're one merge away from being ready for a GWT 2.10 release, 
so I'm starting the release process a bit early, since this last commit 
involves changing GWT's groupId away from com.google and to org.gwtproject.

To that end, I have a maven repo with the maven changes along wit all of 
the other changes in the GWT 2.10 series. The repo's URL is 
https://repo.vertispan.com/gwt-groupid-migration-test/, and the only GWT 
version that exists there is "2.10.0-new-groupid-2".

Based on earlier work (such as in the 
https://groups.google.com/g/google-web-toolkit-contributors/c/L2RMqglOEXo/m/44BeZKeBCQAJ
 
thread), this should allow projects to transition from com.google.gwt to 
org.gwtproject by adding the org.gwtproject:gwt:pom to their project, and 
then specify gwt-user etc, and automatically manage the version of gwt used 
by dependencies. It should also be possible to just use the old groupid for 
this release, but later releases will not have that option.

Please note that *packages are not changing *as part of this transition, 
only groupIds.

Rough release notes:
 * Updated htmlunit and jetty to more recent versions
 * Dropped support for IE8/9/10
 * Dropped support for Java 7
 * Support long classpaths by using CLASSPATH env vars to run child 
permutation workers
 * Many enhancements to emulation APIs and generated code

Please reply to this thread or email me directly with any 
results/surprises/questions.

-- 
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/dad1685b-9ad0-4a1a-88f4-dd0332d7b91dn%40googlegroups.com.

[gwt-contrib] License for gwt-site content

[Colin Alworth]

See the question raised at 
https://github.com/gwtproject/gwt-site/issues/328.

While gwtproject explicitly licenses all "software and sample code" as 
under the Apache License 2.0, it appears that we don't have a license 
specified for the contents of the gwtproject website 
(https://gwtproject.org, https://github.com/gwtproject/gwt-site/). A case 
could be made that the content is already licensed as under the same 
license. It was my understanding that this is discouraged (though at the 
moment I'm having a hard time seeing why that would be). I can find 
concrete examples of the Apache Foundation licensing their documentation 
under the Apache License
 * https://github.com/apache/couchdb-documentation
 * https://github.com/apache/cordova-docs

On the other hand, if the Apache license that applies to all code and 
samples does not apply to the contents, then each author owns their own 
content directly.

I am not a lawyer, but my understanding is that (at least in the country in 
which I reside) content is copyrighted by default, and the author owns that 
copyright. Additional rights must be granted by the author. If we want to 
change the license, we need the approval of the authors so far - 
https://github.com/gwtproject/gwt-site/graphs/contributors. Anyone who 
doesn't approve would need to have their content removed, if we decide to 
change.

Are we sufficiently clear that all content is Apache licensed, including 
the website documentation? Is there a good reason to consider a different 
license instead? Should we seek confirmation from any authors of 
substantial amounts of content that their content falls under the license 
we choose?

My suggestion is to clarify that all content is under the Apache License, 
and see a confirmation from any author who wrote more than ~5 lines of 
content. If we think we are already clear that all content is under that 
license, then we should state that in an up front way, such as setting the 
"license" metadata of the gwt-site repo, and adding a LICENSE file.

Thoughts, suggestions, pointers to how other projects have handled this?

-- 
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/45f473b5-4d2d-4016-b76d-29210128de27n%40googlegroups.com.

Re: URGENT: GWT build crash with out of memory

[Colin Alworth]

Split points are amazingly expensive to compute (in both CPU and memory) - 
I would definitely remove all split points currently under 10KB, and 
strongly consider removing all under 100KB, at least for an application of 
that size. Odds are excellent that your 4043KB file is your "leftovers" 
split point (you can confirm this by checking if the name of the file is 
the largest number in that directory) - if so, it is quite possible that 
removing other tiny split points will decrease the size of the leftovers 
and increase the size of the other larger split points. It may increase the 
initial download size as well, which could tell you that it could be wise 
to carefully put some back, but taking care to merge related split points 
(for example, using GWT.runAsync(Class, RunAsyncCallback) to tell the 
compiler that more than one RunAsyncCallback should be merged as the main 
file).

Consider the order that your files must load in order for the application 
to start up - first, the 1.7MB file loads, and the app is usable until the 
first split point loads. Does that first split point load instantly? Does 
more than one load right away before the app can be used? Consider merging 
those split points, or entirely removing them, if they don't provide some 
concrete benefit (like allowing the user to start logging in while the rest 
of the app is still downloading, etc).

Next, before the very first split point can be loaded, the "leftovers" 
split point is loaded - the split point with the biggest number, in your 
case this would be 756.cache.js (as of your last message). This must be 
downloaded and run before any other split point can be loaded - if this is 
your biggest one by a factor of of almost 10, it might not even make sense 
to have more than a handful of split points, unless you can find a way to 
bring that leftover size down, or possible merge it into the initial split 
point.
On Friday, March 4, 2022 at 8:08:11 AM UTC-6 viny...@gmail.com wrote:

> First of all we are very-very thankful to VIE, FRANK & JENS for their 
> valuable suggestions and are sorry for late reply. As we were busy in 
> applying the solutions suggested by you people.
>
> *AS THE RESULT:-*
> 1. As we have already using "*gwt.compiler.jvmargs=-Xmx61440m*" so we 
> could not get what VIE mean to say.
> 2. As per the suggestion of FRANK we change the logLevel and got the error 
> details and found that some server side classes has been used eg:
>  "*Line 18: No source code is available for type 
> java.util.regex.Pattern; did you forget to inherit a required module?"*
> *  We solved the bugs one-by-one BUT this also not resolved our 
> primary problem*. 
> 3. As per the suggestion of JENS
>  3.1. We used  -optimize *BUT this also not resolved our primary 
> problem*. 
>  3.2. We tried to lower down the split points by 100. As we get near 
> to 756 *.cache.js files. The code started to compile in 35-40 minutes. 
> *   So! the split points were the culprit.*
>
>
> *Now our war file is compiling in 30-40 minutes and we are planning to 
> lower down the split points more.*
>
> *WE ARE VERY THANKFULL TO ALL OF YOU. AS YOUR VALUABLE SUGGESTION HAD 
> SAVED US.*
>
> On Thursday, March 3, 2022 at 6:03:27 AM UTC+5:30 Jens wrote:
>
>> As already said the first thing you should do is to use -strict. This 
>> makes sure GWT compiler does not ignore compile errors. Given you have 12 
>> compile errors, you want to fix them first.
>>
>> Next it looks like you have a lot of split points if you have 856 
>> *.cache.js files. Given that 817 of these files are less than 100kb and 
>> these files are usually gzipped by the web server before transferring to 
>> the client browser, you should try to reduce the amount of split points. I 
>> could imagine that analyzing the code for split point calculation might be 
>> the culprit.
>>
>> There is also an -optimize option for the GWT compiler with values 0 - 9 
>> (0 = no optimizations, 9 = aggressive). I don't recall the default value 
>> but if it is 9 then it will do an optimize loop on the code AST until the 
>> AST does not change anymore. In rare cases this can end up in an endless 
>> loop. Using -optimize 8 usually fixes the issue as the compiler will do at 
>> most 8 optimize loops then. So you might want to try that as well.
>>
>> I have a compiled app that is roughly half the size of yours (about 15 
>> MB) and it compiles fine with just 8 GB Ram. But it only has about 20 split 
>> points.  Using 64GB seems overkill in your case. Maybe you could also try 
>> making a heap dump and analyze it in Eclipse memory analyzer to see what is 
>> consuming all your heap memory. However analyzing a 64GB heap dump won't be 
>> fun either.
>>
>> -- J.
>>
>> viny...@gmail.com schrieb am Dienstag, 1. März 2022 um 16:27:41 UTC+1:
>>
>>> Hi,
>>>
>>> We are having a quite big project, every thing was going in control but 
>>> from last few days our GWT project is crashing while 

[gwt-contrib] gwtproject.org migration, https support

[Colin Alworth]

We've successfully migrated the gwtproject.org website to a new domain name 
server and new hosting, at Google's request. There are a few small 
differences from the old hosting:


   - HTTPS is now supported and enabled, though not yet mandatory, to allow 
   a period of migration, and making sure that no downstream tools will break 
   as a result of these changes. HSTS is also disabled for now. I propose that 
   mid-week I will update this to always redirect to HTTPS, and then in 
   another two or three weeks consider enabling HSTS if there have been no 
   reported issues.
   - The samples.gwtproject.org domain now redirects to the showcase, 
   rather than giving a confusing 500 error. The samples are still at this 
   time hosted as static content rather than servlets.
   - The GWT application that enhances the documentation has been updated, 
   picking up changes published ~2 years ago.
   - Deep links that omit "www." (for example 
   gwtproject.org/doc/latest/DevGuide.html) will now redirect to the expected 
   page (in this case www.gwtproject.org/doc/latest/DevGuide.html) rather than 
   redirecting only to www.gwtproject.org.


Building and deployment of the new site is currently described at 
https://github.com/Vertispan/gwtproject.org, and should be hostable with or 
without DNS entries or HTTPS (though handling your own dns for 
"gwtproject.org" itself may eventually conflict with HSTS). The README 
contains some basic details on how the hosting is structured and how to run 
on any arbitrary server. There is also a TODO list at 
https://github.com/Vertispan/gwtproject.org/blob/main/TODO.md, which could 
eventually be migrated to actual github issues.

This could have been implemented through a similar build process that then 
pushed to github-pages, but at least for now we decided against this. Once 
some kind of continuous integration is in place to create pre-built 
artifacts for gwt-site-webapp and gwt-site itself, it might make sense to 
reconsider this, but for samples it still may make sense to use custom 
hosting to phase out the current static-only samples and provide some 
samples which can interact in some way with the server.

If there are no objections to the current layout, configuration, 
deployment, and documentation, I propose migrating this project to 
github.com/gwtproject, as well as following up on the bullet points of the 
TODO list.

-- 
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/94a1c877-78ac-40ea-9084-405514b8b3d4n%40googlegroups.com.

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

[Colin Alworth]

I've gone ahead and submitted the patches for this work, and have a build 
available (either for maven or just a plain zip download) to test this out, 
along with other features. I only removed explicit references to IE8, 9, 
and 10, as some other code was a bit vague in how it might be used. As IE11 
is still technically supported for a while, and as it behaves as though it 
is a firefox permutation from GWT's perspective, I didn't put any effort at 
this time into removing it.
There are two prerequisite merges that have to happen for this to land:

   - First we need to update the gwt apichecker reference jars 
   https://github.com/gwtproject/tools/pull/22
   - Next, we need to update GWT to use these new reference jars, and 
   account for some api changes since 2.9 that already exist 
   https://gwt-review.googlesource.com/c/gwt/+/23680


Once those are merged, IE 8/9/10 can be removed 
https://gwt-review.googlesource.com/c/gwt/+/23760

As a follow-up, java.util.Date can be substantially more efficient in both 
gwt and j2cl https://gwt-review.googlesource.com/c/gwt/+/23761

See https://github.com/niloc132/gwt/actions/runs/1369212299 for build log 
and artifacts of only these patches. For maven artifacts, use the 
https://repo.vertispan.com/gwt-snapshot/ repository, and specify gwt 
version 2.10.0-htmlunit-upgrade-SNAPSHOT, this build contains other fixes 
as well such as dropping Java7 support, upgrading to latest Jetty 9, and 
upgrading to latest htmlunit.

Community reviewers who have the ability to approve/+2 patches don't seem 
to be available right now, so I request that anyone who tries out these 
patches or builds also look through the code and give a +1 comment or 
review at the links above. I've received private confirmation from several 
individuals and teams that these patches work as expected, but comments to 
that effect on the patches will help to move this forward.

On Tuesday, October 12, 2021 at 3:24:38 AM UTC-5 rdeang...@gmail.com wrote:

>
> +1 for dropping support for all IE versions (8-10)
> Jens schrieb am Mittwoch, 6. Oktober 2021 um 10:22:50 UTC+2:
>
>> I think the gecko permutation has very little to no special treatment of 
>> IE 11 and there are some bugs reported because of that. So there isn't much 
>> to deprecated for IE 11. 
>>
>> Personally I only use safari, gecko permutation and define safari as 
>> fallback permutation. In addition I use some code to check runtime vs 
>> compile time user agent and if they are different display a warning that 
>> some things might not work. That warning basically triggers for any exotic 
>> user-agent and any IE below 11.
>>
>> Dropping all IE permutations (8-10) should be totally fine I guess. 
>> Especially because the new, smaller GWT modules only care about IE 11 (if 
>> at all). gwt-dom for example has only two checks for safari and everything 
>> else is treated the same.
>>
>> -- J.
>>
>> ManfredTremmel schrieb am Montag, 4. Oktober 2021 um 11:07:11 UTC+2:
>>
>>> Am Donnerstag, 30. September 2021, 18:49:56 CEST schrieb Colin Alworth: 
>>>
>>> > 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. 
>>>
>>> Let's drop the IE-Permutations. IE11 uses the gecko permutation, so no 
>>> need to 
>>> drop it. In my newer projects, I only use safari permutation for all 
>>> browsers, 
>>> so even dropping all browser specific permutations wouldn't affect me. 
>>>
>>>
>>>

-- 
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/98f32124-392c-47a4-8424-54e2a1c99934n%40googlegroups.com.

Re: GWT 2.9 compatiblity with GXT 2.3.1a

[Colin Alworth]

The short answer is yes, you need to do this for each such bug you find, 
and if you have a commercial license, you need to do it yourself - the only 
way to distribute fixes for things like this is under GPLv2, which may not 
be something you want in your project as a dependency. 

If this is a gwt compiler error, editing bytecode is not sufficient, as GWT 
consumes the source each time it builds. You probably should also update 
the bytecode if you update the source files. Only the file in question 
needs to be edited in this way (HtmlEditor, ListField are the ones I know 
of).

Do not replace with a .toString() call, in case the model holds an explicit 
null value, casting to object will use StringBuilder.append(Object), which 
will be null safe, or pick some other null safe approach.

Sencha's release policy at the time was that they supported the last major 
release - this means that until GXT 4 was released, GXT 2 was supported, 
and got updates, but once 4.0.0 was available, GXT 2 was no longer 
supported. To my knowledge, GXT isn't receiving any updates at all any 
more. Combined with the license issues, it is hard to do more than discuss 
the possible fixes and how they could be applied.

On Thursday, October 14, 2021 at 11:08:14 PM UTC-5 RT wrote:

> Yes, I agree changing the line in the GXT 2.3.1a ListField.java file from:
> sb.append(m.get(prop));
>
> To this:
> sb.append(m.get(prop).toString());
>
> Would seemingly fix the issue. However I would then need to compile this 
> to a .class file to replace the one in the gxt-2.3.1a-gwt22,jar that I 
> reference in my project and therein lies the problem.  Must I track down 
> all the dependencies for GXT and GWT so that I can do a full recompile from 
> source just for this one line change? Or can I use a java byte code editor 
> to simply insert the .toString() at the right place in the .class file for 
> ListField? I'm not sure how to do that, so I'll have to read up on byte 
> code editors as that seems easier than a full recompile - if I knew where 
> and how to inject the .toString()
>
> However if the OP already had GXT 2.3.1a working with GWT 2.8.2 then I'm 
> guessing they already had to do this operation, and may be able to provide 
> some insight. Unless they were using Java 7 and this is only a Java 8 issue 
> perhaps.
>
> On Wednesday, October 13, 2021 at 5:48:47 PM UTC-5 nilo...@gmail.com 
> wrote:
>
>> The updated JDT probably caused this (so that gwt 2.8.2 can support Java 
>> 8 language features) - at a guess you'll need to cast the result of 
>> m.get(prop) on that line to Object so that StringBuilder.append correctly 
>> uses the Object overload.
>>
>> On Wednesday, October 13, 2021 at 3:41:52 PM UTC-5 RT wrote:
>>
>>> Hi, I am attempting to update to GWT 2.8.2 from 2.7.0 using GXT 2.3.1a 
>>> however I get the following error:
>>> Errors in 
>>> 'jar:file:/war/WEB-INF/lib/gxt-2.3.1a-gwt22.jar!/com/extjs/gxt/ui/client/widget/form/ListField.java'
>>>  Line 322: The method append(boolean) is ambiguous for the type 
>>> StringBuffer
>>>
>>> How were you able to get 2.8.2 working with 2.3.1a?  I'm running Java 8 
>>> with compiler compliance set to 1.7
>>>
>>> On Thursday, June 11, 2020 at 7:13:31 AM UTC-5 priyako...@gmail.com 
>>> wrote:
>>>
 Hi All,

 Currently our application has below versions -
 1. GWT - 2.8.2
 2. GXT - 2.3.1a

 We are planning to upgrade GWT from 2.8.2 to 2.9.0. But have query 
 regarding its compatibility towards GXT 2.3.1a.
 I have gone through GXT Compatiblity version matrix page 
 , 
 but found nowhere officially mentioned that its supported.
 So can you please confirm that GWT 2.9 is officially supported with GXT 
 2.3.1a?

>>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/82fcc7c6-9397-470c-b76e-0c29dbf7ccdan%40googlegroups.com.

Re: [gwt-contrib] Re: GWT 2.10 release?

[Colin Alworth]

I'm looking for reviewers and help for the above issues so I can finalize 
them and begin testing. There are a few dependency chains here - I have 
IE8/9/10 removal just about complete, but before that can merge we need the 
apichecker updated, and after that merges, we can remove the poorly 
performing java.util.Date.fixDaylightSavings call. Likewise before 
htmlunit/jetty can be upgraded, Java 7 support must be dropped and the new 
jars put in the tools repo.

Here are reviews currently waiting for someone to take a look:

   - Fix Chrome+SDM stack traces 
   https://gwt-review.googlesource.com/c/gwt/+/23500
   - Fix Chrome -XmethodDisplayName 
   https://gwt-review.googlesource.com/c/gwt/+/23580
   - Provide GWT 2.9.0 apicheck jars 
   https://github.com/gwtproject/tools/pull/22
   - Permit GWT 2.10.0 breaking api changes 
   https://gwt-review.googlesource.com/c/gwt/+/23680 (depends on tools#22)
   - Drop support for Java 7 
   https://gwt-review.googlesource.com/c/gwt/+/23700

After these start to land (to avoid too many at a time), will be the 
following:

   - Drop IE8/9/10 support (depends on review 23680 above)
   - Improve java.util.Date performance in both gwt2 and j2cl (depends on 
   dropping IE8/9)
   - Add latest HtmlUnit/Jetty to gwtproject/tools
   - Update Htmlunit/Jetty to latest (depends on dropping java7 support and 
   htmlunit/jetty being in tools) - this is somewhat incomplete, there are two 
   dev mode tests that are failing, and jetty-env.xml is not presently loaded 
   correctly
   - Add Github Actions support - this depends on the patch which drops 
   Java 7 support due to some issue in running the validation tests in that 
   environment. I'm attempting to replicate build.gwtproject.org except in a 
   way that is visible, and can deploy snapshots to the org.gwtproject groupId 
   when we're ready for that.
   
If you have +2 permissions in the review site, I'd appreciate a look at 
some of these, if you are interested in trying out the patches and giving a 
+1 that would help other reviewers as well.

On Tuesday, October 12, 2021 at 8:01:02 AM UTC-5 juan_pablo_gardella wrote:

> @co...@colinalworth.com  do yo know any ETA on this?
>
> On Tue, Oct 12, 2021, 5:28 AM Rocco De Angelis  
> wrote:
>
>>
>> Nice +1 
>> chani...@gmail.com schrieb am Dienstag, 5. Oktober 2021 um 16:38:08 
>> UTC+2:
>>
>>> Thank a millon, looks great ! +1
>>>
>>> On Friday, October 1, 2021 at 2:55:21 p.m. UTC-4 krypto...@gmail.com 
>>> wrote:
>>>
 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 

Re: GWT 2.9 compatiblity with GXT 2.3.1a

[Colin Alworth]

The updated JDT probably caused this (so that gwt 2.8.2 can support Java 8 
language features) - at a guess you'll need to cast the result of 
m.get(prop) on that line to Object so that StringBuilder.append correctly 
uses the Object overload.

On Wednesday, October 13, 2021 at 3:41:52 PM UTC-5 RT wrote:

> Hi, I am attempting to update to GWT 2.8.2 from 2.7.0 using GXT 2.3.1a 
> however I get the following error:
> Errors in 
> 'jar:file:/war/WEB-INF/lib/gxt-2.3.1a-gwt22.jar!/com/extjs/gxt/ui/client/widget/form/ListField.java'
>  Line 322: The method append(boolean) is ambiguous for the type 
> StringBuffer
>
> How were you able to get 2.8.2 working with 2.3.1a?  I'm running Java 8 
> with compiler compliance set to 1.7
>
> On Thursday, June 11, 2020 at 7:13:31 AM UTC-5 priyako...@gmail.com wrote:
>
>> Hi All,
>>
>> Currently our application has below versions -
>> 1. GWT - 2.8.2
>> 2. GXT - 2.3.1a
>>
>> We are planning to upgrade GWT from 2.8.2 to 2.9.0. But have query 
>> regarding its compatibility towards GXT 2.3.1a.
>> I have gone through GXT Compatiblity version matrix page 
>> , 
>> but found nowhere officially mentioned that its supported.
>> So can you please confirm that GWT 2.9 is officially supported with GXT 
>> 2.3.1a?
>>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/fc89baa3-122c-4f34-a1dd-278e64980bbbn%40googlegroups.com.

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

[Colin Alworth]

Note that it appears I'm mistaken, Runtime.java polyfilled Date.now() 
(though code in JsDate and others still believed that this method might not 
exist), so GWT 2.8.2 and 2.9.0 likely function properly in IE8.

On Thursday, September 30, 2021 at 11:49:56 AM UTC-5 Colin Alworth 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.
>>

[gwt-contrib] GWT 2.10 release?

[Colin Alworth]

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 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/1cd1088d-474e-459f-9f99-d16ca54710ffn%40googlegroups.com.

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

[Colin Alworth]

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 much overhead in code size and performance doing 
>>> (cached) runtime checks instead.
>>>
>>> -- 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-co...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/031f1171-cce9-4c17-b717-80bb5730f7fdn%40googlegroups.com
>>>  
>>> 

[gwt-contrib] Re: Documentation of compiler optimisations?

[Colin Alworth]

GWT itself hasn't changed substantially in many years - improvements have 
mostly been language features, adding support for incremental compilation, 
the jsinterop system, etc, so for the most part the optimizations haven't 
changed.

That said, the best way is almost certainly to take a look at the source 
code itself, and the JavaToJavaScriptCompiler class has the high level 
aspects of this. This is a different way to look at the current process, 
but might give you helpful insights in contrast to the link you shared.

Starting in the compilePermutation() method: 
https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java#L304-L467
This method is well commented, showing the order of operations that take 
place. Optimizations on Java source itself largely happens at the 
optimizeJava() method, which itself does very little, just check if it 
should run, and if so, invokes optimizeJavaToFixedPoint(), then applies one 
last optimization: RemoveEmptySuperCalls. optimizeJavaToFixedPoint() can be 
found at 
https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java#L1415-L1457
though it largely just invokes optimizeJavaOneTime in a loop until the code 
stops changing, and follows up with one optional run to the 
DataflowOptimizer. optimizeJavaOneTime can be found at
https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java#L1492-L1517
Here you can see the optimizations that happen in the main optimization 
loop, with a small handful of notes on the order that these must take place.

After this we're back to the compilerPermutation method, which finishes 
normalizing the code to JS and continuing to optimize this lightly, though 
not in a loop, just a few specific passes.




On Thursday, October 1, 2020 at 3:52:04 PM UTC-5 George Georgovassilis 
wrote:

> Is there an up-to-date documentation of optimisations the compiler 
> applies? An older page [1] discusses some topics but it isn't clear what of 
> that has been implemented.
> (apologies for posting here, I asked this question on the user forum [2] 
> but didn't get any replies)
>
> [1] 
> https://github.com/gwtproject/old_google_code_wiki/blob/master/AdvancedCompilerOptimizations.wiki.md
> [2] https://groups.google.com/g/google-web-toolkit/c/aOBvgbKjjcw
>
>

-- 
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/35d8b2c8-59a7-4e4c-a252-08ba7cb07fe6n%40googlegroups.com.

Re: [gwt-contrib] Thurs July 16 2020 GWT community call

[Colin Alworth]

It went well - it was a smaller crowd, probably in part due to fewer "talks" 
and more "contrib", but that's a balance we're going to have to continue to 
strike.

The main focus was on getting closure to provide the sort of optimization we've 
come to expect from gwt2, and we had a surprisingly large amount of difficulty 
in getting it to do this. I'm doing a writeup now for the closure compiler 
list, since we've got a fairly simple set of plain example JS that demonstrates 
the issue. The biggest concern is that this means that you have to use raw JS 
to "explain" this pattern to the compiler, otherwise it will not understand and 
will not bother to prune/optimize code, but our guess right now is that this is 
a specific enough of a use case that we can provide tooling to solve this 
problem, and that tooling can generate JS instead of developers writing it. 
Also worth noting that j2cl+closure has been at least on par with gwt2 if not 
smaller in the examples we've tried so far, so especially if it tends to 
generate sub-optimal code in a few cases, we know it is doing a far better job 
than gwt2 in other cases. 

Next week we have two talks planned already, and have room for 1-2 more if 
anyone is interested. As usual, the call will start an hour early with no set 
topic, instead anyone can ask questions or make suggestions on what we can 
discuss. 
https://calendar.google.com/event?action=TEMPLATE=MXVmcmw1czU5cHMxYm5lcHEzZWQ0MjR2ODUgY29saW5AdmVydGlzcGFuLmNvbQ=colin%40vertispan.com

-- 
  Colin Alworth
  co...@colinalworth.com



On Tue, Jul 21, 2020, at 8:24 AM, Michael Conrad wrote:
> How did it go?
> 
> 
> On 7/15/20 5:02 PM, Colin Alworth wrote:
>> We have a shorter itinerary this week - I'll record a short piece on 
>> j2cl-maven-plugin and how to start a project with it, try using pieces from 
>> the ecosystem.
>> 
>> Dmitrii, Ahmad and I will continue our brainstorming about efficiently 
>> producing both optimized output and minimizing the work the compiler does 
>> for i18n/cldr generated code.
>> 
>> 
> 
> 

> --
> 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/864efc55-2de0-3db7-be88-e3fe9170da42%40newsrx.com
>  
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/864efc55-2de0-3db7-be88-e3fe9170da42%40newsrx.com?utm_medium=email_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/17bf2f7e-77ca-4fd7-959b-e2412f0047c0%40www.fastmail.com.

[gwt-contrib] Thurs July 16 2020 GWT community call

[Colin Alworth]

We have a shorter itinerary this week - I'll record a short piece on 
j2cl-maven-plugin and how to start a project with it, try using pieces from 
the ecosystem.

Dmitrii, Ahmad and I will continue our brainstorming about efficiently 
producing both optimized output and minimizing the work the compiler does 
for i18n/cldr generated code.

We'll probably also continue poking around j2cl/closure output to recap 
what we learned about string concatenation last time, understand why this 
makes sense, possibly try to make the output improve a bit.

The first video from last call was published earlier this week, the second 
one will probably go out tomorrow. The first video can be found at 
https://www.youtube.com/watch?v=7uFUoL1vpMI, we'll continue to publish the 
other videos to the same channel.

We'll get started at our usual time, 5pm CEST / 11am EDT. The call will be 
on Google Meet again, but we're open to options that can record at a higher 
resolution and not force the presenter's picture into frame and hurt 
readability.

https://meet.google.com/aru-fdpg-cjf

-- 
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/dbcbb3f4-e093-4235-89b7-9f8b9a65846bo%40googlegroups.com.

Re: Problem decoding complex AutoBean

[Colin Alworth]

I'm not seeing any issue with that code and sample JSON. Here's a quick 
entrypoint that I made:

@Override
public void onModuleLoad() {
IWebchatThemeConfigurationBean bean = deserializeFromJson("{\n" +
"\"themeId\": 1,\n" +
"\"name\": \"rpc\",\n" +
"\"enabled\": true,\n" +
"\"propertiesList\": [\n" +
"{\n" +
"\"id\": 1,\n" +
"\"themeConfigurationId\": 1,\n" +
"\"chatScreen\": \"chatScreen\",\n" +
"\"component\": \"header\",\n" +
"\"property\": \"text\",\n" +
"\"value\": \"HELLO\"\n" +
"},\n" +
"{\n" +
"\"id\": 3,\n" +
"\"themeConfigurationId\": 1,\n" +
"\"chatScreen\": \"chatScreen\",\n" +
"\"component\": \"background\",\n" +
"\"property\": \"color\",\n" +
"\"value\": \"rgba(0,191,255,0.5)\"\n" +
"}\n" +
"]\n" +
"}");
DomGlobal.console.log(bean.getEnabled());
DomGlobal.console.log(bean.getThemeId() + "");
DomGlobal.console.log(bean.getName());
DomGlobal.console.log(String.valueOf(bean.getPropertiesList()));
DomGlobal.console.log(bean.getPropertiesList().size() + "");

DomGlobal.console.log(bean.getPropertiesList().stream().map(IWebchatThemeConfigurationPropertyBean::getValue).collect(Collectors.joining(",
 
")));
}


Notice that after running your parse method, it dumps the output to the JS 
console - here is the output:
true
1
rpc
[com.vertispan.draw.connected.client.FlowChartEntryPoint_IWebchatThemeConfigurationPropertyBeanAutoBean$2@1b,
 
com.vertispan.draw.connected.client.FlowChartEntryPoint_IWebchatThemeConfigurationPropertyBeanAutoBean$2@1c]
2
HELLO, rgba(0,191,255,0.5)

It seems to be working?

One note: if you do not actually call the properties() method, it is not 
needed in the factory, since the IWebchatThemeConfigurationPropertyBean 
type is already reachable from IWebchatThemeConfigurationBean.

Using GWT 2.8.2 for this test.

On Friday, July 10, 2020 at 3:23:35 PM UTC-5, Akshay Kumar wrote:
>
> Can anyone help me?
> My json string is - 
> {
> "themeId": 1,
> "name": "rpc",
> "enabled": true,
> "propertiesList": [
> {
> "id": 1,
> "themeConfigurationId": 1,
> "chatScreen": "chatScreen",
> "component": "header",
> "property": "text",
> "value": "HELLO"
> },
> {
> "id": 3,
> "themeConfigurationId": 1,
> "chatScreen": "chatScreen",
> "component": "background",
> "property": "color",
> "value": "rgba(0,191,255,0.5)"
> }
> ]
> }
>
> Interfaces are -
>
> public interface IWebchatThemeConfigurationBean { public Integer 
> getThemeId(); public String getName(); public Boolean getEnabled(); public 
> List getPropertiesList(); }
> public interface IWebchatThemeConfigurationPropertyBean { public Integer 
> getId(); public Integer getThemeConfigurationId(); public String 
> getChatScreen(); public String getComponent(); public String getProperty(); 
> public String getValue(); }
>
> public interface ChatFactory extends AutoBeanFactory {
> AutoBean theme();
>
> AutoBean properties();
> }
> ChatFactory factory;
> factory = GWT.create(ChatFactory.class);
>
> IWebchatThemeConfigurationBean deserializeFromJson(String json) { 
> AutoBean bean = 
> AutoBeanCodex.decode(factory, IWebchatThemeConfigurationBean.class, json); 
> return bean.as(); }
>
> in this returned bean I'm getting null propertiesList.
> name, enabled, themeId are fine.
>
> On Tuesday, August 20, 2013 at 8:07:30 AM UTC+5:30, Thad Humphries wrote:
>>
>> I've managed a simple AutoBean with a list. Now I've a more complex one, 
>> and I don't understand what's wrong. My get methods are returning null 
>> though the debugger shows the object has data.
>>
>> The JSON looks like this:
>>
>> {
>>   "mquery":
>> {
>>   "screenname":"Index Card",
>>   "fields":
>> {
>>   "field":[
>> {"title":"Name",  "name":"odname",   "value":"*TIFF*"},
>> {"title":"Date",  "name":"oddate",   "value":""},
>> {"title":"Ref #", "name":"odrefnum", "value":""}
>>   ]
>> }
>> }
>> } 
>>
>>
>> I have three interfaces:
>>
>> public interface Field {
>>   String getTitle();
>>   void setTitle(String title);
>>   String getName();
>>   void setName(String name);
>>   String getValue();
>>   void setValue(String value);
>> }
>>
>> public interface FieldList {
>>   List getField();
>>   void setField(List field);
>> }
>>
>> public interface MQuery {
>>   String getScreenname();
>>   void setScreenname(String screenname);
>>   FieldList getFields();
>>   void 

Re: GWT Server and debug

[Colin Alworth]

Yes, remove -nosuperDevMode.

On Tuesday, July 7, 2020 at 5:02:19 AM UTC-5, Jasper Suijker wrote:
>
> Hi,
>
> We are running with 2.8.2 and want to migrate to 2.9.0 later on.
> this is my current gwt server start with arguments:
> Main class: 
>   com.google.gwt.dev.DevMode
> arguments: 
>com.test.demo.webclient
>   -war GWT/war
>   -nosuperDevMode
>   -startupUrl demo
>
> What do i need to change to make it start in superdevmode? (remove 
> -nosuperDevMode?)
>
> regards,
>
> Jasper
>
>
> Op dinsdag 7 juli 2020 02:14:06 UTC+2 schreef Thomas Broyer:
>>
>> gwt.codesrv is a sign that you're using the deprecated so-called 
>> "classic" DevMode, that relies on a browser plugin, that indeed only works 
>> in Internet Explorer nowadays.
>> If you haven't already, then first upgrade to at least GWT 2.7.0 (of 
>> course 2.9.0 would be a lot better),
>> then you'll be able to use SuperDevMode the same way as you're used to 
>> run DevMode, except you don't have to install any plugin: just load the 
>> page in your browser and it'll automatically trigger the compilation of 
>> your code.
>> Your code will then run in JS in your browser, and you'll debug it from 
>> your browser's developer tools, leveraging source maps (Chrome or Edge work 
>> better, likely Safari too; Firefox used to be sluggish but that was 
>> supposed to be better in recent versions, haven't tried it yet though).
>> See http://www.gwtproject.org/articles/superdevmode.html to learn more 
>> about SuperDevMode.
>>
>> On Monday, July 6, 2020 at 5:05:13 PM UTC+2, Jasper Suijker wrote:
>>>
>>> LS,
>>>
>>> We are using GWT to get our Swing gui available in web.
>>> This works nicely. After compiling, we deploy our application in tomcat 
>>> and it runs and shows the same screens as we have in Swing.
>>>
>>> Now we want to debug the web parts through the gwt Jetty server. (GWT 
>>> development mode)
>>> To be able to debug, you Start the jetty server and it will give you a 
>>> url like: http://127.0.0.1:/?gwt.codesvr=127.0.0.1:9997
>>> The part after the question mark is the magic of the GWT server, being 
>>> able to debug your code. As far as i know this only works in Internet 
>>> Explorer, is that correct?
>>>
>>> Internet Explorer is terrible to work with, the javascript engine is 
>>> terrible and large memory usage, etc
>>> Microsoft is already pushing users towards Edge, so Internet explorer 
>>> will stop at some point..
>>> Is there another way to debug GWT?
>>>
>>> Regards,
>>>
>>> Jasper
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/057e4f32-d3ce-4401-ac04-40db4c2d3141o%40googlegroups.com.

[gwt-contrib] Re: Thurs July 2 2020 GWT community call

[Colin Alworth]

Meeting link is at https://meet.google.com/jbs-wier-ywp - we will start 
recording in about an hour, and will only publish the three talks listed 
below.

On Wednesday, July 1, 2020 at 12:58:15 PM UTC-5, Colin Alworth wrote:
>
> We're going to try recording tomorrow, just for the specific 'sessions' 
> that are planned, so the video should be available afterward, I'll link in 
> a follow up post when they are ready.
>
> Three planned topics to record:
>  * Ahmad Bawaneh presenting domino-history, a simple routing tool to 
> manipulate the url and browser history, based on the pushState API, but 
> intended to be usable in other platforms like the JVM in the future
>  * Rafat Al-Barouki presenting domino-rest, a follow up to Ahmad's talk 
> last time on domino-jackson, this tool lets you take jax-rs interfaces and 
> generate gwt/android/jvm compatible clients with no runtime reflect
>  * Frank Hossfeld presenting gwt-editor, a quick talk to show how to move 
> an existing project to the annotation-processor based editor framework
>
> We'll also have a probably-unrecorded discussion looking at some modern 
> compiled web applications to identify if GWT is being used, looking at some 
> of the differences and similarities between closure-compiled j2cl and gwt2 
> output.
>
> The talks will formally start at 5pm CEST / 11am EDT, but the call will be 
> available to join about an hour earlier, I'll share a link to join here. 
> Outside of the sessions above, nothing will be recorded, and we'll probably 
> be discussing other topics around contributing to the gwt ecosystem - main 
> topic this week will be revisiting internationalization and reducing dev 
> mode and prod mode code size.
>

-- 
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/f1a6d70d-da6b-4443-b868-e0ca38b85188o%40googlegroups.com.

[gwt-contrib] Thurs July 2 2020 GWT community call

[Colin Alworth]

We're going to try recording tomorrow, just for the specific 'sessions' 
that are planned, so the video should be available afterward, I'll link in 
a follow up post when they are ready.

Three planned topics to record:
 * Ahmad Bawaneh presenting domino-history, a simple routing tool to 
manipulate the url and browser history, based on the pushState API, but 
intended to be usable in other platforms like the JVM in the future
 * Rafat Al-Barouki presenting domino-rest, a follow up to Ahmad's talk 
last time on domino-jackson, this tool lets you take jax-rs interfaces and 
generate gwt/android/jvm compatible clients with no runtime reflect
 * Frank Hossfeld presenting gwt-editor, a quick talk to show how to move 
an existing project to the annotation-processor based editor framework

We'll also have a probably-unrecorded discussion looking at some modern 
compiled web applications to identify if GWT is being used, looking at some 
of the differences and similarities between closure-compiled j2cl and gwt2 
output.

The talks will formally start at 5pm CEST / 11am EDT, but the call will be 
available to join about an hour earlier, I'll share a link to join here. 
Outside of the sessions above, nothing will be recorded, and we'll probably 
be discussing other topics around contributing to the gwt ecosystem - main 
topic this week will be revisiting internationalization and reducing dev 
mode and prod mode code size.

-- 
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/309b9227-0b54-4f94-b14b-e31df9c73b24o%40googlegroups.com.

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

[Colin Alworth]

Okay, sounds good, I think these are compatible goals. Restating here to make 
sure I understood clearly, then I'll make a few notes on the existing tickets, 
new tickets to track this:
 * ant test (more or less) should correctly filter out java9+ jre emulation 
tests when run from Java 8. All tests will be run in Java 11 (or Java.latest, 
when we add tests that require a newer JDK)
 * ant dist-dev should run correctly in Java 8, Java 11, and Java.latest
 * Based on the current status of javadoc, ant dist will for now run on Java8 
only, then later only on any Java9+. (elemental hasnt actually been removed 
yet, but I have a patch for it...)

Steps to achieve this, roughly in order:
 * Remove Java 7/8 filters in ant wiring, make everything run cleanly/simply on 
Java 8 alone
 * Finish making the distribution part of the code run cleanly on Java >=9 
(https://gwt-review.googlesource.com/c/gwt/+/22640 is the last step until this 
is finished)
 * Update build to skip any doc tasks when on Java >8
 * Add Java <11 filters to ant wiring, allowing specific tests to be excluded 
when running on something older than Java 11 in anticipation of this emulation 
to be finished, landed.
 * Update Javadoc to support >8 only, update build to skip any doc tasks when 
on Java 8



On Wed, Jul 1, 2020, at 11:34 AM, Thomas Broyer wrote:
> 
> 
> On Wednesday, July 1, 2020 at 3:32:34 AM UTC+2, Colin Alworth wrote:
>> Thanks Goktug for clarifying - I am personally in favor of a more coarse 
>> approach, more future proofed approach that will end up with making changes 
>> now rather than later. And to your followup, agreed, all else equal, let's 
>> avoid supersource.
>> 
>> Thomas - While I made a Java8-first option was the first bullet at the end 
>> of my email, I deliberately skipped the option of "we can either produce 
>> build artifacts, or test the output, but not both in the same build", but it 
>> may be worth considering, even if it means each release has to be built 
>> twice.
>> 
>> My thinking on the javadoc wiring is that it is better done once, and better 
>> done sooner than later. There are other advantages to modernizing the 
>> javadoc: dropping the deprecated API, search, etc. If the concern is only 
>> saving the effort of this work, then I'm happy to own this task, if we think 
>> it would be preferred to only produce output artifacts using Java8 then it 
>> seems it wouldn't make sense to try it at all, at least until we get closer 
>> to something resembling a Java 8 EOL, or find ourselves needing a baseline 
>> higher than Java 8 for other reasons. That is, optimizing for 
>> minimum-effort-today has its advantages, but my current mindset was to seek 
>> to future proof a bit, as long as I'm excising Java7-specific things and 
>> ensuring other code builds on Java9+.
>> 
>> With the assumption that Javadoc is handled, is there any objection to 
>> requiring Java 11+ to run tests, Java 9+ to produce a complete build? It 
>> sounds like this is the direction everyone is moving, only supporting tests 
>> in a limited range of versions, only supporting releases in a limited range 
>> of versions (or, just one), or is the objection specifically to dropping 
>> Java 8 as the build version of choice?
> 
> I'm concerned with dropping JDK 8 testing. If we want to make sure it works 
> with JDK 8, we have to test with JDK 8. If we want to make sure it works with 
> JDK 11, we have to test with JDK 11. (IMO, supporting JDK14, then 15, etc. 
> would only be a bonus)
> Given how Ant works, this probably does not mean *building* (the non-test 
> code) with either, i.e. we could probably build and test with JDK8 
> (JAVA_HOME=… ant build) and then run tests with JDK 11 (JAVA_HOME=… ant test, 
> in the same directory, reusing the classes already compiled by the previous 
> build with the other JDK), or the reverse.
> Of course, it also depends what we want to test!
> Unfortunately, JDK 8 and JDK 9+ are different enough (at runtime) that we'd 
> really want to test both (AFAIK, we(you) only did smoke tests with JDK 11 for 
> GWT 2.9.0, and smoke tests might actually be enough)
> 
> So, what do we want to achieve?
>  * Make it possible to "ant dist-dev" and "ant test" with JDK 11 (or even 
> 14)? to run JDK9+ specific tests (and make it easier for anyone to contribute)
>  * Make it possible to "ant clean elemental dist" with JDK 11 (or even 14)? 
> (this could/would mean dropping support for JDK 8 for "ant doc", but keep 
> "ant dist-dev" and "ant test" working)
> In any case, I believe we should keep "ant dist-dev" and "ant test" working 
> with both JDK 8 

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

[Colin Alworth]

eans we have to run the build twice 
>>> when cutting 
>>>  a release: once with JDK.lts/JDK.latest to make sure the tests 
>>> pass, and 
>>>  then once with JDK8 to actually build the artifacts.
>>>  - con: requires setting up the new JDKs, and new jobs, on the 
>>>  CI server. If we keep using the current build.gwtproject.org, 
>>>  this puts the burden on Google; that'd likely precipitate the 
>>> replacement 
>>>  of the server.
>>>  - con: requires 2 builds to make sure things still build/run 
>>>  with JDK8
>>>   - Supersourcing
>>>   - pro: tests can run with JDK8, so the whole build is 
>>>   JDK8-compatible and still covers all tests
>>>   - con: requires somehow maintaining the tests twice, keeping the 
>>>   javac'd and supersourced versions in sync (AFAIK, the javac'd version 
>>> has 
>>>   to have the test methods so they're detected by JUnit, even if their 
>>> body 
>>>   is empty; so it would be rather easy to add a test to the 
>>> supersourced 
>>>   version and never actually run it because the method is missing from 
>>> the 
>>>   javac'd version)
>>>
>>> The situation requiring the minimum effort in the short term would be 
>>> keeping the doclets as they are and using supersourcing for the tests.
>>> In the long run, as JDK9+ tests grow, supersourcing might become 
>>> unsustainable, but the impact on the CI server et al. is non-negligible. We 
>>> could still possibly, at least temporarily, build only with JDK8, and only 
>>> run the JDK9+ tests once in a while (at release time?), manually on a 
>>> developer's machine as a smoke test.
>>>
>>> So, my vote would be: "require JDK8 for javadoc, supersource tests", 
>>> with a fallback to an option you didn't list: "Allow any JDK 8+, use ant 
>>> filters, only actually produce javadoc on JDK8 builds", and if/when someone 
>>> wants to put the effort then migrate the doclets and move on to your third 
>>> option: "allow any JDK8+, use ant filters, only actually produce javadoc on 
>>> JDK9+ builds"
>>>
>>> On Tuesday, June 30, 2020 at 3:45:36 AM UTC+2, 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 firs

Re: GWT SingleUploader gets stuck

[Colin Alworth]

It looks like this isn't part of GWT itself, but an external library. 
Here's a stackoverflow post i found from a few years ago that seems to 
address your issue: 
https://stackoverflow.com/questions/31424639/gwt-error-when-uploading-file-with-singleuploader

It looks like the project might live on in github, but there has been 
minimal activity there: https://github.com/manolo/gwtupload/. Check the 
network of forks for more updated versions to see if one of them might be 
the "new home" for this project? https://github.com/manolo/gwtupload/network

On Tuesday, June 30, 2020 at 8:52:36 AM UTC-5, ahmdt wrote:
>
> When I upload a file using SingleUploader or MultiUploader, the file gets 
> uploaded but the uploader's progress bar gets stuck at 0% for a very, very 
> long time.
>
> When I try to upload a second file in the same session, I get this message:
>  
>
>> There is already an active upload, try later. 
>>
>>
>
> This is my code:
>
> final SingleUploader uploader = new SingleUploader();
> uploader.setAutoSubmit(false);
> uploader.setMultipleSelection(false);
> uploader.setValidExtensions(".log");
> uploader.setServletPath("/reprocess/"+userTestXml);
> uploader.avoidRepeatFiles(false);
>
>
>  Any advice here?
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/f942772a-5013-4910-9b5d-6ea0c10eeadao%40googlegroups.com.

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

[Colin Alworth]

Right - the excludes via ant are certainly an option ("use ant filters"), my 
main hope is to avoid adding another stanza of xml for the emulation for each 
release. Cutting out Java7 and adding a "java 11 or higher" to lump all the 
java 9, 10, 11 tests in would at least be a net equal in XML from what we have 
today (since compiling under Java 7 isn't an option), but still a bit messier 
than I'd like - especially if we agree that "run all internal tests in Java11" 
is reasonable (plus another few build steps to validate the build under other 
versions of Java). 

If that isn't deemed reasonably, we'll need a Java9 check (for the new of() 
methods), Java 10 check (new optional methods, collections copyOf), Java 11 
check (string methods) to get caught up with the JDT we're using today, and 12, 
13, 14 are out now, with 15 soon. Again, not impossible, just perhaps messy - 
and unwinding the "java8" flag (which really seems to mean "newer than java7") 
is less fun than I'd like.

-- 
 Colin Alworth
co...@colinalworth.com



On Mon, Jun 29, 2020, at 9:21 PM, 'Goktug Gokdogan' via GWT Contributors 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
>> 
>

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

[Colin Alworth]

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.

Re: Security Vulnerabilities with GWT

[Colin Alworth]

The gwt-servlet issue is only on c++ versions of protobuf, so we believe there 
is no exploit here at all.

The other issues are all specific to gwt-dev, and neither gwt-dev.jar nor 
gwt-user.jar should ever be deployed as part of a running server application, 
so none of those should be exploitable either. 


On Mon, Jun 29, 2020, at 10:38 AM, Velusamy Velu wrote:
> Is there a documented or demonstrated case of break-in using any of the 
> vulnerabilities listed in your post, in an application developed with GWT 
> framework? Do these vulnerabilities matter if a GWT application doesn't use 
> GWT's RPC?
> 
> On Monday, June 29, 2020 at 6:57:41 AM UTC-4, Priya Kolekar wrote:
>> 
>> Hi All,
>> 
>> Security Vulnerability have been detected in gwt-dev.jar & 
>> gwt-servlet.jar(in release 2.8.2) & are reported by Dependency checker tool 
>> .
>> 
>> Below are the details -
>> 
>> Gwt-dev.jar -
>> 1.1 Vulnerable version of jetty library(current version-- 9.2.14, available 
>> version -9.2.27+ )
>> 1.2 Vulnerable version of commons-collections(current version - 3.2.1)
>> 1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current 
>> version - 4.3.1)
>> 1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, available 
>> version - 3.4.0)
>> 1.5 Vulnerable version of htmlunit ( current version - 2.19 , available 
>> version- 2.37)
>> 
>> Gwt-servlet.jar -
>>  1.1 Vulnerable version of Google Protobuf(current version - 2.5.0, 
>> available version - 3.4.0)
>> 
>> Given above vulnerabilities -
>> 1. Are those security issues addressed in latest 2.9.0 release?
>> 2. If no, is there a plan to include them in any future release say 3.x?
>> 3. As we know that gwt-dev.jar is used for development purpose & can be 
>> flagged as false positive, still are there any attack surfaces exists?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/8226e012-160a-49b2-91a6-b41a958da81a%40www.fastmail.com.