Wednesday, June 11, 2025

Re: Need Help: GWT 2.12 Migration + gwtrpc-spring-1.02 Compatibility Issue

I have stopped using RPC for years now. But I would suggest to copy the one class >>SpringRemoteServiceServlet<< of gwtrpc-spring  your project and change the import from >>javax.servlet<< to >>jakarta.servlet<< and of course, remove the dependency.

Arpan Ameta schrieb am Mittwoch, 11. Juni 2025 um 14:59:41 UTC+2:

We're currently migrating our legacy project from GWT 2.8.1 to GWT 2.12.0 to be compatible with JDK 17 and modern tooling. As part of this upgrade, we've updated the dependency from:

<dependency>
    <groupId>org.gwtrpcspring</groupId>
    <artifactId>gwtrpc-spring</artifactId>
    <version>1.01</version>
</dependency>

To :

<dependency>
    <groupId>org.gwtrpcspring</groupId>
    <artifactId>gwtrpc-spring</artifactId>
    <version>1.02</version>
</dependency>

We're facing the following challenges:

  • Deployment fails in WildFly 33, throwing NoClassDefFoundError for javax.servlet.http.HttpServlet, which seems to originate from RemoteServiceServlet in the GWT RPC stack.

  • The artifact gwtrpc-spring:1.02 isn't resolving from Maven Central, and the old configured repo http://www.mvnsearch.org/maven2/ is timing out.

  • We're unsure if gwtrpc-spring 1.02 is compatible with GWT 2.12 and Jakarta EE 9+ (jakarta.servlet) changes.

📌 Has anyone successfully used gwtrpc-spring with GWT 2.12 and JDK 17?
📌 Any fork or alternative for gwtrpc-spring compatible with modern GWT and WildFly?
📌 Suggestions on resolving servlet dependencies (HttpServlet) when deploying in WildFly 33?

Any help, pointers, or even working examples would be greatly appreciated! 🙏

Thanks in advance!
— Arpan

--
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/42f9d56e-168e-47e6-96d1-f4d817260941n%40googlegroups.com.

Need Help: GWT 2.12 Migration + gwtrpc-spring-1.02 Compatibility Issue

We're currently migrating our legacy project from GWT 2.8.1 to GWT 2.12.0 to be compatible with JDK 17 and modern tooling. As part of this upgrade, we've updated the dependency from:

<dependency>
    <groupId>org.gwtrpcspring</groupId>
    <artifactId>gwtrpc-spring</artifactId>
    <version>1.01</version>
</dependency>

To :

<dependency>
    <groupId>org.gwtrpcspring</groupId>
    <artifactId>gwtrpc-spring</artifactId>
    <version>1.02</version>
</dependency>

We're facing the following challenges:

  • Deployment fails in WildFly 33, throwing NoClassDefFoundError for javax.servlet.http.HttpServlet, which seems to originate from RemoteServiceServlet in the GWT RPC stack.

  • The artifact gwtrpc-spring:1.02 isn't resolving from Maven Central, and the old configured repo http://www.mvnsearch.org/maven2/ is timing out.

  • We're unsure if gwtrpc-spring 1.02 is compatible with GWT 2.12 and Jakarta EE 9+ (jakarta.servlet) changes.

📌 Has anyone successfully used gwtrpc-spring with GWT 2.12 and JDK 17?
📌 Any fork or alternative for gwtrpc-spring compatible with modern GWT and WildFly?
📌 Suggestions on resolving servlet dependencies (HttpServlet) when deploying in WildFly 33?

Any help, pointers, or even working examples would be greatly appreciated! 🙏

Thanks in advance!
— Arpan

--
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/c8b79b25-64f3-48ce-b56a-b8c1f8904284n%40googlegroups.com.

Monday, June 2, 2025

Re: GWT at JCON 2025!

Happy birthday to Java!  Definitely my favourite language.  😊

Cool presentation.  Those old UIs bring back some memories!

Not sure I agree with "Text and voice chat will be the only frontends in the future".  Suspect that precise controls will generally always be with a UI.  Kind of like my car is now.  I can say "I'm hot" and it lowers the temperature.  Or if I want fine control, I can click the UI button to make it half a degree cooler.

On Monday, 2 June 2025 at 7:10:01 pm UTC+10 Lonzak wrote:
Browsed your presentation  - thank you for sharing! Remembered some of the long forgotten UI technologies :-)
Regarding the third wave I recently watched a video from the microsoft CEO who envisioned something similar... The future of UI developers will become pretty interesting...

Hi All,

Ingo and I had a chance in JCON 2025 doing this session...

"History of Java UI Development: Live. Die. Repeat."

We really enjoyed talking about the evolution of #Java UI development—from the early days of desktop UIs to modern web browser interfaces. I demonstrated a "Hello World" example using a simple #GWT-style Java-to-JavaScript transpiler. Interestingly, many developers still aren't aware of the key differences between GWT-based UI frameworks like DominoUI and server-side browser UI frameworks like #Vaadin Flow. GWT-based frameworks don't require a backend at all. They transpile Java source code into JavaScript, allowing the resulting web app to run entirely in the browser—just like any other JavaScript application.

Unfortunately, we didn't have enough time to dive deeper into what we see as the most exciting development: "The Third Wave" – Everything is a Chat. In our view, UI development is undergoing a major shift. In an #AI-first world, the UI becomes just a simple chat—based on text, voice, video, or images—while an AI agent (#LLM == The Brain) decides what UI elements to display to the user. This changes everything. There will be far less need for complex UI frameworks, goodbye#Vue, #React, and the era of rigid, form-based interfaces may soon be over.

Here are our slides—enjoy!

https://bit.ly/ai-llm-ui

By the way, we also included some nice photos of Cologne and Münster for Java developers looking for travel inspiration in Germany. Both cities are definitely worth a visit!

--
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/ada6e20d-6fce-4531-94ee-bc2486a7b53an%40googlegroups.com.

Re: GWT at JCON 2025!

Browsed your presentation  - thank you for sharing! Remembered some of the long forgotten UI technologies :-)
Regarding the third wave I recently watched a video from the microsoft CEO who envisioned something similar... The future of UI developers will become pretty interesting...

Hi All,

Ingo and I had a chance in JCON 2025 doing this session...

"History of Java UI Development: Live. Die. Repeat."

We really enjoyed talking about the evolution of #Java UI development—from the early days of desktop UIs to modern web browser interfaces. I demonstrated a "Hello World" example using a simple #GWT-style Java-to-JavaScript transpiler. Interestingly, many developers still aren't aware of the key differences between GWT-based UI frameworks like DominoUI and server-side browser UI frameworks like #Vaadin Flow. GWT-based frameworks don't require a backend at all. They transpile Java source code into JavaScript, allowing the resulting web app to run entirely in the browser—just like any other JavaScript application.

Unfortunately, we didn't have enough time to dive deeper into what we see as the most exciting development: "The Third Wave" – Everything is a Chat. In our view, UI development is undergoing a major shift. In an #AI-first world, the UI becomes just a simple chat—based on text, voice, video, or images—while an AI agent (#LLM == The Brain) decides what UI elements to display to the user. This changes everything. There will be far less need for complex UI frameworks, goodbye#Vue, #React, and the era of rigid, form-based interfaces may soon be over.

Here are our slides—enjoy!

https://bit.ly/ai-llm-ui

By the way, we also included some nice photos of Cologne and Münster for Java developers looking for travel inspiration in Germany. Both cities are definitely worth a visit!

--
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/f4e3fd83-eca3-406f-8296-e0c14c735b6dn%40googlegroups.com.

Friday, May 30, 2025

Re: Calling methods on Uint8Array is causing a ReferenceError in Super Dev Mode...

Aaaand
After clean SuperDevMode restart (after deletion of GWT temp files in gradle build and in Windows TEMP folder) everything works as expected.
(I'm posting it as advice instead of removing my post so people with similar problems will have an option)

On Friday, May 30, 2025 at 7:34:17 PM UTC+2 tekkyru wrote:
I face similar problem, trying to use ArrayBuffer and Uint8Array. JDK 17, GWT 2.12.1, Windows workstation

My original intent was to return bytes of user-selected file from JSNI to GWT code. But now I see even simplest pure GWT java code doesn't work. 
I create ArrayBuffer, then create Uint8Array from it.
Any Uint8Array methods except toString() fail with ReferenceError. I see "devirtual" there, may it give a clue...

I probably do something wrong but I cannot find any example in the internet.

ArrayBuffer arrayBuffer = TypedArrays.createArrayBuffer(20);

GWT.log("ab.length = " + arrayBuffer.byteLength());

Uint8Array uintArray = TypedArrays.createUint8Array(arrayBuffer);

GWT.log("uintArray = " + uintArray);

// ---------- THE CALL BELOW FAILS ---------

GWT.log("uintArray[0] " + uintArray.get(0));


ab.length = 20
uintArray = 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
SEVERE ****MYAPP**** Exception: com.google.gwt.core.client.JavaScriptException: (ReferenceError) : com_google_gwt_typedarrays_client_Uint8ArrayNative_get_1I_1S_1_1devirtual$__Lcom_google_gwt_typedarrays_shared_Uint8Array_2IS is not defined
at Unknown. ***MYAPP*** _testArrayBuffer__V(***MYAPP***-0.js@3:260605)
at ....

--------------
JDK 17
GWT 2.12.1
Code server Command line:

Run GWT Code Server: [-launcherDir, C:\home\ws\MYAPP\.metadata\.plugins\org.eclipse.wst.server.core\tmp0/wtpwebapps/MYAPP, -workDir, MYTMPDIR, -logLevel, INFO, -style, DETAILED, -sourceLevel, 17, -port, 9876, -generateJsInteropExports, MYAPPNAME]


On Saturday, November 11, 2017 at 8:11:08 PM UTC+1 Colin Alworth wrote:
Can you run super dev mode with `-style PRETTY`? The line you are pointing at should only error out like that if createUint8Array returned null, but it would be good to confirm that in PRETTY you see the name of the local variable.

.byteLength() in the native code is just defined as access on the .byteLength field of the view, so that seems sane enough - should only error out of there is no Uint8Array. But createUint8Array should just delegate to Uint8ArrayNative.create(buffer, 0, buffer.byteLength()) anyway, which just calls the JS constructor, so that doesn't make a ton of sense either...

Try PRETTY, and maybe turn off sourcemaps so you can see what is generated - perhaps there is a bug and SDM is making a mistake, or maybe something else will be clear to you once you see the sources (probably in your own JSNI).

Finally, which version of GWT are you using?


On Wednesday, November 8, 2017 at 7:58:09 PM UTC-6, TimOnGmail wrote:
Hmmm, nope - even if I make a copy of the buffer, I still get the above error in Super Dev mode.

Any ideas, anyone?

- Tim


--
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/7b953dd4-e268-4abe-964a-bc23ce085535n%40googlegroups.com.

Re: Calling methods on Uint8Array is causing a ReferenceError in Super Dev Mode...

I face similar problem, trying to use ArrayBuffer and Uint8Array. JDK 17, GWT 2.12.1, Windows workstation

My original intent was to return bytes of user-selected file from JSNI to GWT code. But now I see even simplest pure GWT java code doesn't work. 
I create ArrayBuffer, then create Uint8Array from it.
Any Uint8Array methods except toString() fail with ReferenceError. I see "devirtual" there, may it give a clue...

I probably do something wrong but I cannot find any example in the internet.

ArrayBuffer arrayBuffer = TypedArrays.createArrayBuffer(20);

GWT.log("ab.length = " + arrayBuffer.byteLength());

Uint8Array uintArray = TypedArrays.createUint8Array(arrayBuffer);

GWT.log("uintArray = " + uintArray);

// ---------- THE CALL BELOW FAILS ---------

GWT.log("uintArray[0] " + uintArray.get(0));


ab.length = 20
uintArray = 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
SEVERE ****MYAPP**** Exception: com.google.gwt.core.client.JavaScriptException: (ReferenceError) : com_google_gwt_typedarrays_client_Uint8ArrayNative_get_1I_1S_1_1devirtual$__Lcom_google_gwt_typedarrays_shared_Uint8Array_2IS is not defined
at Unknown. ***MYAPP*** _testArrayBuffer__V(***MYAPP***-0.js@3:260605)
at ....

--------------
JDK 17
GWT 2.12.1
Code server Command line:

Run GWT Code Server: [-launcherDir, C:\home\ws\MYAPP\.metadata\.plugins\org.eclipse.wst.server.core\tmp0/wtpwebapps/MYAPP, -workDir, MYTMPDIR, -logLevel, INFO, -style, DETAILED, -sourceLevel, 17, -port, 9876, -generateJsInteropExports, MYAPPNAME]


On Saturday, November 11, 2017 at 8:11:08 PM UTC+1 Colin Alworth wrote:
Can you run super dev mode with `-style PRETTY`? The line you are pointing at should only error out like that if createUint8Array returned null, but it would be good to confirm that in PRETTY you see the name of the local variable.

.byteLength() in the native code is just defined as access on the .byteLength field of the view, so that seems sane enough - should only error out of there is no Uint8Array. But createUint8Array should just delegate to Uint8ArrayNative.create(buffer, 0, buffer.byteLength()) anyway, which just calls the JS constructor, so that doesn't make a ton of sense either...

Try PRETTY, and maybe turn off sourcemaps so you can see what is generated - perhaps there is a bug and SDM is making a mistake, or maybe something else will be clear to you once you see the sources (probably in your own JSNI).

Finally, which version of GWT are you using?


On Wednesday, November 8, 2017 at 7:58:09 PM UTC-6, TimOnGmail wrote:
Hmmm, nope - even if I make a copy of the buffer, I still get the above error in Super Dev mode.

Any ideas, anyone?

- Tim


--
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/834cbe43-1d08-47b4-b36e-2575b6b149bdn%40googlegroups.com.

Thursday, May 29, 2025

GWT at JCON 2025!

Hi All,

Ingo and I had a chance in JCON 2025 doing this session...

"History of Java UI Development: Live. Die. Repeat."

We really enjoyed talking about the evolution of #Java UI development—from the early days of desktop UIs to modern web browser interfaces. I demonstrated a "Hello World" example using a simple #GWT-style Java-to-JavaScript transpiler. Interestingly, many developers still aren't aware of the key differences between GWT-based UI frameworks like DominoUI and server-side browser UI frameworks like #Vaadin Flow. GWT-based frameworks don't require a backend at all. They transpile Java source code into JavaScript, allowing the resulting web app to run entirely in the browser—just like any other JavaScript application.

Unfortunately, we didn't have enough time to dive deeper into what we see as the most exciting development: "The Third Wave" – Everything is a Chat. In our view, UI development is undergoing a major shift. In an #AI-first world, the UI becomes just a simple chat—based on text, voice, video, or images—while an AI agent (#LLM == The Brain) decides what UI elements to display to the user. This changes everything. There will be far less need for complex UI frameworks, goodbye#Vue, #React, and the era of rigid, form-based interfaces may soon be over.

Here are our slides—enjoy!

https://bit.ly/ai-llm-ui

By the way, we also included some nice photos of Cologne and Münster for Java developers looking for travel inspiration in Germany. Both cities are definitely worth a visit!

--
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/1124095e-0516-4f8a-bce2-e53749c0db92n%40googlegroups.com.