Tuesday, March 11, 2025

Re: GWT, Java 17, jakarta.servlet, Eclipse, GWT plugin

Does anyone have an example of how to setup the embedded server with dev mode, or even better, super dev mode? I'm upgrading a large Gradle-based enterprise application from Spring 5 to Spring 6 and migrated from javax to jakarta and have had constant issues from Jetty's compatibility problems. 

Any pointers would be a tremendous help. I'm currently trying to use tomcat-catalina-10.1 as the embedded server but have not been able to get it to start properly. 

On Monday, June 17, 2024 at 9:09:58 PM UTC-5 Craig Mitchell wrote:
It's when you see crazy long command lines like that, you start to appreaciate Maven (or Gradle).  The same command in Maven is "mvn gwt:codeserver -pl *-client" (yes, I know you see still need to setup the launcherDir, warDir, etc in the pom.xml files, but that seems much easier than one huge command line).

On Tuesday 18 June 2024 at 2:17:26 am UTC+10 Jens wrote:
> If using maven... [I'm not]... If not, please give us more detail about what you are using (or intend to use).
After further investigation, much of my issues around this seem to be that the. appropriate java command to run the web app (or Jetty itself) is not being assembled correctly by either Eclipse, the GWT plugin, or both.  There are various options that are needed and are not properly set.  That said, even if I do/can get that working, I don't think that's the right approach.  As you're going to deprecate the embedded Jetty server, I should do whatever is needed there to run my own external server(s).  That's what's unclear to me.  There are ancient references to it in the documentation at gwt.project.org, but I'm unclear on what is really needed.  Do I need to set up and run a code server with my own Jetty or Tomcat local installation?  If so, how is that set up?  Or do I need to run my own app server (again, either Jetty or Tomcat).  The web app setup is obvious (I think... or are there special runtime parameters to direct it to the proper code server port?).  Forgive my ignorance on this, but if this is the path forward for GWT in general, I'd really like to see some clear documentation on how to set this up or at least what it is going to look like (in general, no specifics, obviously it should involve thinking and work on my part). Last note: I am assuming the code server will be easier to get working with Java 17 modules because it will (in my case) have less jar dependencies, as it only needs them for shared and client code.  That said... I might need to run both externally to get it all sorted out.  Again, my own thinking on this isn't that clear because I'm not in the weeds enough on what the plugin is really doing and how things work under the hood.

To give a shorter, more direct answer: I want to develop code in Eclipse in Java 17, and be able to run the code server and web app any way possible, so that GWT code compiles/recompiles as needed, and the web app can be accessed in the browser, and I can do iterative test-code-test-code development on a daily basis.

Traditionally GWT SDK only had the class com.google.gwt.dev.DevMode. It is responsible to launch classic dev mode (the one that does require an obsolete browser plugin) or SuperDevMode together with an embedded servlet container, by default Jetty. SuperDevMode is implemented in class com.google.gwt.dev.codeserver.CodeServer and DevMode basically calls this class if you request it to launch SuperDevMode (which is the default behavior). Class DevMode has a parameter "-noserver" which skips starting Jetty and assumes you have your own server and deployment running. Because we advocate running your own servlet container, e.g. Jetty/Tomcat/..., it is enough to just launch CodeServer yourself. However you could also continue to use class DevMode and replace the embedded Jetty with your own implementation using DevMode -server your.impl.of.ServletContainerLauncher. Your own implementation could then be based on Jetty 12 for example (and possibly jakarta)

Personally I use Gradle and have a task that just launches CodeServer by executing a command line. I am pretty sure you could also write a similar ANT task using your current ANT setup. The command line looks like 

com.google.gwt.dev.codeserver.CodeServer -sourceLevel 11 -strict -failOnError - bindAddress 0.0.0.0 -port 9876 -style PRETTY -XmethodNameDisplayMode ABBREVIATED -workDir /client-project/build/gwt/work -launcherDir /client-project/build/gwt/war -src /shared-project/src/main/java -src /shared-project/src/main/resources com.example.MyGwtModule

The classpath should contain gwt-user/gwt-dev/gwt-codeserver, all compile-time dependencies you need for GWT compilation as well as classes + sources + resources related to your GWT UI and DTOs. You would need to use ANT fileset/dirset/files to include/exclude only the files of your single project that are relevant for GWT compilation. Once you have that set of files figured out you can run GWT CodeServer in isolation via ANT with its own GWT focused classpath and you should not have any trouble with other dependencies that you need on the server only.

Once you have that running, you need to decide how you want to run a servlet container. Personaly I use Docker + docker-compose + Jetty image + shell script.

 

--
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/e391c8f6-c957-481a-bd83-8f9cf1803353n%40googlegroups.com.

Monday, March 10, 2025

Re: JSON.stringfy() doesn't preserve propery names

If you just need to create a JSON string, you can create it yourself with com.google.gwt.json.client.JSONObject:

JSONObject myObj = new JSONObject();
myObj.put("foo", new JSONString("bar"));
String myJsonStr =  myObj.toString();

But usually, Colins ways are better if you have direct mapping between your Java classes.

On Tuesday, 11 March 2025 at 3:04:41 am UTC+11 Colin Alworth wrote:
Java field naming rules don't mesh well with user expectations for how JSON.stringify and friends work - for example it is totally legal for a Java subclass to hide a superclass's fields if not private, and if they are private, a subclass and superclass can have the same field name with no hiding at all. To compile these possible states to JS, some other naming has to be used to ensure consistency. This wouldn't so much be "disabling obfuscation", but "no longer guaranteeing correctness".

Roughly two options are available to you:
 * Use a tool like AutoBeans or domino-jackson so that JSON can be created from your Java types, in a way that would be familiar to a Java developer
 * Write your Java like a JS developer would, but annotate with JsInterop to indicate that you plan to always follow JS naming rules (only one constructor ever, no overloaded methods, etc)

If you're writing something quick and simple and never plan on it growing to more than a few properties, I'd lean towards jsinterop - just slap "@JsProperty" on the fields in question (non-long primitives, Boolean or Double boxed primitives, Strings, arrays, and other annotated types, never java collections etc) and call it good. If it may grow or you like your Java to make sense in Java, give domino-jackson a look to use most of the Jackson annotations and generate json marshalling code.

On Monday, March 10, 2025 at 10:52:58 AM UTC-5 anb...@gmail.com wrote:
I'm trying to serialize an object using JSON.stringify(), however since the GWT complier shortens/obfuscates the property names, the resulting JSON has propery names like "a" and "b" instead of the original names, which means that the JSON can't be deserialized by the server because the property names don't match what it expects.

I've tried turning PRETTY style on for the GWT complier, but even then it seems to still change some property names.

Is there any way to tell the GWT compiler to exempt certain classes from obfuscation? Or some easy alternative way to serialize/deserialize JSON? I don't want to have to write a serializer code separately for each 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/65ac9dce-f386-4bc4-99ab-853599042490n%40googlegroups.com.

Re: JSON.stringfy() doesn't preserve propery names

Java field naming rules don't mesh well with user expectations for how JSON.stringify and friends work - for example it is totally legal for a Java subclass to hide a superclass's fields if not private, and if they are private, a subclass and superclass can have the same field name with no hiding at all. To compile these possible states to JS, some other naming has to be used to ensure consistency. This wouldn't so much be "disabling obfuscation", but "no longer guaranteeing correctness".

Roughly two options are available to you:
 * Use a tool like AutoBeans or domino-jackson so that JSON can be created from your Java types, in a way that would be familiar to a Java developer
 * Write your Java like a JS developer would, but annotate with JsInterop to indicate that you plan to always follow JS naming rules (only one constructor ever, no overloaded methods, etc)

If you're writing something quick and simple and never plan on it growing to more than a few properties, I'd lean towards jsinterop - just slap "@JsProperty" on the fields in question (non-long primitives, Boolean or Double boxed primitives, Strings, arrays, and other annotated types, never java collections etc) and call it good. If it may grow or you like your Java to make sense in Java, give domino-jackson a look to use most of the Jackson annotations and generate json marshalling code.

On Monday, March 10, 2025 at 10:52:58 AM UTC-5 anb...@gmail.com wrote:
I'm trying to serialize an object using JSON.stringify(), however since the GWT complier shortens/obfuscates the property names, the resulting JSON has propery names like "a" and "b" instead of the original names, which means that the JSON can't be deserialized by the server because the property names don't match what it expects.

I've tried turning PRETTY style on for the GWT complier, but even then it seems to still change some property names.

Is there any way to tell the GWT compiler to exempt certain classes from obfuscation? Or some easy alternative way to serialize/deserialize JSON? I don't want to have to write a serializer code separately for each 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/4ea75f5b-9df3-43d7-94fd-796261563150n%40googlegroups.com.

JSON.stringfy() doesn't preserve propery names

I'm trying to serialize an object using JSON.stringify(), however since the GWT complier shortens/obfuscates the property names, the resulting JSON has propery names like "a" and "b" instead of the original names, which means that the JSON can't be deserialized by the server because the property names don't match what it expects.

I've tried turning PRETTY style on for the GWT complier, but even then it seems to still change some property names.

Is there any way to tell the GWT compiler to exempt certain classes from obfuscation? Or some easy alternative way to serialize/deserialize JSON? I don't want to have to write a serializer code separately for each 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/e0463f53-109d-4c73-95dd-d9c965a0a292n%40googlegroups.com.

Monday, March 3, 2025

Re: GWT 2.12.2 released

Working great.  And addWindowClosingHandler works again!  Thanks all!

On Tuesday, 4 March 2025 at 5:02:56 am UTC+11 Juan Pablo Gardella wrote:
Thanks everyone!! I'll check it out

On Mon, Mar 3, 2025 at 1:20 PM Colin Alworth <co...@colinalworth.com> wrote:
Two more issues with the 2.12 release have been discovered and fixed. The 2.12.2 release is available for download from https://github.com/gwtproject/gwt/releases/tag/2.12.2 and from Maven Central.

Two bug fixes:
- Fixed a regression in Window.onClosing() that prevented the closing event from being fired in cases where the deprecated closed event was not also being listened for.
- Support JDT's implicit yield in switch statements. Perhaps not technically a "regression", but trivial switch statements that update to use "->" instead of "break" were compiling to incorrect JavaScript.

Thanks for everyone who reported these bugs, contributed fixes, and helped us test!

--
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 visit https://groups.google.com/d/msgid/google-web-toolkit/97a9dc81-9020-4e38-b1f4-32ca0a2c30bcn%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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/d5cb87cd-6032-43ce-a92c-3df922892fe6n%40googlegroups.com.

Re: GWT 2.12.2 released

Thanks everyone!! I'll check it out

On Mon, Mar 3, 2025 at 1:20 PM Colin Alworth <colin@colinalworth.com> wrote:
Two more issues with the 2.12 release have been discovered and fixed. The 2.12.2 release is available for download from https://github.com/gwtproject/gwt/releases/tag/2.12.2 and from Maven Central.

Two bug fixes:
- Fixed a regression in Window.onClosing() that prevented the closing event from being fired in cases where the deprecated closed event was not also being listened for.
- Support JDT's implicit yield in switch statements. Perhaps not technically a "regression", but trivial switch statements that update to use "->" instead of "break" were compiling to incorrect JavaScript.

Thanks for everyone who reported these bugs, contributed fixes, and helped us test!

--
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/97a9dc81-9020-4e38-b1f4-32ca0a2c30bcn%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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/CA%2BkiFsdir%2Bs%2Btf2A7cX6M52p2O3OEX3VjV_9WF17gkvTrrHbWw%40mail.gmail.com.

GWT 2.12.2 released

Two more issues with the 2.12 release have been discovered and fixed. The 2.12.2 release is available for download from https://github.com/gwtproject/gwt/releases/tag/2.12.2 and from Maven Central.

Two bug fixes:
- Fixed a regression in Window.onClosing() that prevented the closing event from being fired in cases where the deprecated closed event was not also being listened for.
- Support JDT's implicit yield in switch statements. Perhaps not technically a "regression", but trivial switch statements that update to use "->" instead of "break" were compiling to incorrect JavaScript.

Thanks for everyone who reported these bugs, contributed fixes, and helped us test!

--
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/97a9dc81-9020-4e38-b1f4-32ca0a2c30bcn%40googlegroups.com.