Sunday, February 15, 2026

Re: Re-loading back-end code while system is running

I noticed that you can change front-end code without rebooting the system and rebuilding.  However, this doesn't seem true about the back-end code.  Am I missing something?

Going forward GWT will only provide a simple server to serve static files out of the box. If you want DevMode to launch an application server for your server side code you have to use "-server com.google.gwt.dev.shell.JettyLauncher" to get the implementation GWT had always provided (but it will be removed in a future release) or provide your own implementation of GWTs "ServletContainerLauncher".  If you use a proper build tool with separated modules for GWT code and for server code you usually already have some mechanism to launch your app server. Also the coupling GWT did before always produced classpath issues. 

So going forward it is up to the developer to serve the backend code.

 
Also, since I originally used GWT, I have learned HTML, CSS, JavaScript, etc.  Now I feel like it is easier to specify layout in HTML/CSS than using all of that GWT Java code.  GWT front-end code seems incredibly verbose.  That leads me to two questions:

1. Can I use HTML/CSS?  If so, are there examples?

GWT SDK provides UiBinder which allows you to write XML documents with a matching Java class and GWT will generate an additional Java class from the XML document to glue both together, see: https://www.gwtproject.org/doc/latest/DevGuideUiBinder.html

It is still a bit verbose compared to JS frameworks which support two way databinding and plain HTML but it is good enough if you like to read HTML instead of code.

 
2. Is there a graphical GUI system that allows someone to graphically design an interface and have it generate all of that Java code for the front-end?

There was an Eclipse plugin called GWT Designer, but I think it does not work anymore. I am not aware of anything else. Your best bet is probably using UiBinder XML and some AI help.

 
Lastly, and just FYI, in response to what Google did with GWT at that time, I ended up writing my own open-source, full-stack web development framework.  In addition to being able to change front-end code while developing, it also supports changing back-end code without having to reboot the server or recompile anything.  It also has built-in support for microservices, REST (actually JSON-RPC), authentication, custom HTML controls, SQL API, reporting, CSV import/export, crypto, LLM interfaces, and a lot more.  It has been used in production systems for a few years now.  It's at kissweb.org

Sounds interesting. 

For GWT related libraries you can take a look at https://github.com/gwtboot/gwt-boot-awesome-lili


-- J.

--
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/b64a93d2-a14f-495f-b9b3-514d3db71afen%40googlegroups.com.
Posted by at No comments:

Re-loading back-end code while system is running

Greetings,

I built an app in GWT back when Google was developing it.  It worked okay and avoided HTML & CSS, which I didn't know at that time.  When Google dropped browser support for GWT, I dropped GWT.

Out of curiosity, I downloaded the latest GWT.  Interesting.  I see you've solved the front-end debugging issues.  Nice!

I noticed that you can change front-end code without rebooting the system and rebuilding.  However, this doesn't seem true about the back-end code.  Am I missing something?

Also, since I originally used GWT, I have learned HTML, CSS, JavaScript, etc.  Now I feel like it is easier to specify layout in HTML/CSS than using all of that GWT Java code.  GWT front-end code seems incredibly verbose.  That leads me to two questions:

1. Can I use HTML/CSS?  If so, are there examples?

2. Is there a graphical GUI system that allows someone to graphically design an interface and have it generate all of that Java code for the front-end?

Lastly, and just FYI, in response to what Google did with GWT at that time, I ended up writing my own open-source, full-stack web development framework.  In addition to being able to change front-end code while developing, it also supports changing back-end code without having to reboot the server or recompile anything.  It also has built-in support for microservices, REST (actually JSON-RPC), authentication, custom HTML controls, SQL API, reporting, CSV import/export, crypto, LLM interfaces, and a lot more.  It has been used in production systems for a few years now.  It's at kissweb.org

Thanks!

Blake McBride

--
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/CABwHSOsAw%3DE2ih0_ghTNR%2B70YqSu2P1LFzvjG5Zt9E8xAWO2jA%40mail.gmail.com.
Posted by at No comments:

Saturday, February 14, 2026

Re: GWT Code Server Jetty Mismatch

Awesome!  Thanks Colin.  Yes, moving the spring-boot-dependencies from the top level, into the server module, fixes it.  🎉

On Sunday, 15 February 2026 at 4:07:51 am UTC+11 eliasb...@gmail.com wrote:
I am aligned with controlling the transitive dependencies versions on a top level module, as I faced such complexities and used the same approach, in groups of solutions.

Particularly with overlapping dependency chains and SpringBoot , I had to override the Jetty versions among others in parent Maven modules.

I am guessing Gradle can do similar but I think it is known for its fragility in my point of view.

I hope this helps.

On Saturday, 14 February 2026 at 15:51:28 UTC Colin Alworth wrote:
That's an irritating outcome for sure - though updating GWT to Jetty 12.1.5 only punts on the issue, since the next time Spring Boot wants a different Jetty version (or some other library) we end up back in this mess (though likely with a much more subtle failure mode).

Gradle does a much better job at letting you break up classpaths here, at the cost of dramatically increased complexity in the worst case - but it could allow you to specify each bom in its own classpath configuration, rather than mix the two together.

I think I have a solution that works for your project, but I'm going to try to reason it out here a bit, so someone can poke holes in my logic:
  • The GWT wiring here is configured for the parent project pom, so that the plugin can run from there if desired. 
  • The server BOM is also declared in the parent project pom, so that we just have it in one place. This probably makes sense for large enough projects where it needs to be reused - but at least for this project it seems unnecessary.
What I did was to move the jetty bom into test-server:
diff --git a/pom.xml b/pom.xml
index bb3edc3..ae118dc 100644
--- a/pom.xml
+++ b/pom.xml
@@ -24,13 +24,6 @@
         <type>pom</type>
         <scope>import</scope>
       </dependency>
-      <dependency>
-        <groupId>org.springframework.boot</groupId>
-        <artifactId>spring-boot-dependencies</artifactId>
-        <version>${spring-boot.version}</version>
-        <type>pom</type>
-        <scope>import</scope>
-      </dependency>
       <dependency>
         <groupId>org.yaml</groupId>
         <artifactId>snakeyaml</artifactId>
diff --git a/test-server/pom.xml b/test-server/pom.xml
index 6dbf708..31426c0 100644
--- a/test-server/pom.xml
+++ b/test-server/pom.xml
@@ -16,6 +16,17 @@
     <maven.compiler.target>17</maven.compiler.target>
   </properties>
 
+  <dependencyManagement>
+    <dependencies>
+      <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-dependencies</artifactId>
+        <version>${spring-boot.version}</version>
+        <type>pom</type>
+        <scope>import</scope>
+      </dependency>
+    </dependencies>
+  </dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>${project.groupId}</groupId>

Then, I was able to build and start the server, and start the devmode server. I did not go so far as to make changes yet, but I'm not familiar with how spring boot likes to work for "dev" mode.

On Friday, February 13, 2026 at 4:55:11 PM UTC-6 ma...@craig-mitchell.com wrote:
I raised a Spring Boot Jetty issue https://github.com/spring-projects/spring-boot/issues/49220 because I thought there was an issue with Jetty.

Turns out, the GWT Code Server is bringing in an old version of Jetty which breaks Spring Boot.

When I tell Spring Boot to use the version of Jetty it wants, the GWT Code Server then breaks with the error:

[WARNING] java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/ContextHandler$Context
[WARNING]       at com.google.gwt.dev.codeserver.WebServer.start(WebServer.java:125)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:162)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:104)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:55)
[WARNING] Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.server.handler.ContextHandler$Context
[WARNING]       at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
[WARNING]       at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
[WARNING]       at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
[WARNING]       ... 4 more
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for test 1.0-SNAPSHOT:
[INFO]
[INFO] test ............................................... FAILURE [  4.688 s]
[INFO] test-shared ........................................ SKIPPED
[INFO] test-client ........................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.436 s
[INFO] Finished at: 2026-02-14T09:25:21+11:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal net.ltgt.gwt.maven:gwt-maven-plugin:1.2.0:codeserver (default-cli) on project test: Process exited with an error: 1 (Exit value: 1) -> [Help 1]

Is there a way to allow Spring Boot to use Jetty 12.1.5, but also let the GWT Code Server use Jetty 9.4.58?

(Apologies if this has been asked before, I searched around and couldn't find it)

--
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/7e499e41-4180-43cb-87ac-ddb7cbd3297en%40googlegroups.com.
Posted by at No comments:

Re: GWT Code Server Jetty Mismatch

I am aligned with controlling the transitive dependencies versions on a top level module, as I faced such complexities and used the same approach, in groups of solutions.

Particularly with overlapping dependency chains and SpringBoot , I had to override the Jetty versions among others in parent Maven modules.

I am guessing Gradle can do similar but I think it is known for its fragility in my point of view.

I hope this helps.

On Saturday, 14 February 2026 at 15:51:28 UTC Colin Alworth wrote:
That's an irritating outcome for sure - though updating GWT to Jetty 12.1.5 only punts on the issue, since the next time Spring Boot wants a different Jetty version (or some other library) we end up back in this mess (though likely with a much more subtle failure mode).

Gradle does a much better job at letting you break up classpaths here, at the cost of dramatically increased complexity in the worst case - but it could allow you to specify each bom in its own classpath configuration, rather than mix the two together.

I think I have a solution that works for your project, but I'm going to try to reason it out here a bit, so someone can poke holes in my logic:
  • The GWT wiring here is configured for the parent project pom, so that the plugin can run from there if desired. 
  • The server BOM is also declared in the parent project pom, so that we just have it in one place. This probably makes sense for large enough projects where it needs to be reused - but at least for this project it seems unnecessary.
What I did was to move the jetty bom into test-server:
diff --git a/pom.xml b/pom.xml
index bb3edc3..ae118dc 100644
--- a/pom.xml
+++ b/pom.xml
@@ -24,13 +24,6 @@
         <type>pom</type>
         <scope>import</scope>
       </dependency>
-      <dependency>
-        <groupId>org.springframework.boot</groupId>
-        <artifactId>spring-boot-dependencies</artifactId>
-        <version>${spring-boot.version}</version>
-        <type>pom</type>
-        <scope>import</scope>
-      </dependency>
       <dependency>
         <groupId>org.yaml</groupId>
         <artifactId>snakeyaml</artifactId>
diff --git a/test-server/pom.xml b/test-server/pom.xml
index 6dbf708..31426c0 100644
--- a/test-server/pom.xml
+++ b/test-server/pom.xml
@@ -16,6 +16,17 @@
     <maven.compiler.target>17</maven.compiler.target>
   </properties>
 
+  <dependencyManagement>
+    <dependencies>
+      <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-dependencies</artifactId>
+        <version>${spring-boot.version}</version>
+        <type>pom</type>
+        <scope>import</scope>
+      </dependency>
+    </dependencies>
+  </dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>${project.groupId}</groupId>

Then, I was able to build and start the server, and start the devmode server. I did not go so far as to make changes yet, but I'm not familiar with how spring boot likes to work for "dev" mode.

On Friday, February 13, 2026 at 4:55:11 PM UTC-6 ma...@craig-mitchell.com wrote:
I raised a Spring Boot Jetty issue https://github.com/spring-projects/spring-boot/issues/49220 because I thought there was an issue with Jetty.

Turns out, the GWT Code Server is bringing in an old version of Jetty which breaks Spring Boot.

When I tell Spring Boot to use the version of Jetty it wants, the GWT Code Server then breaks with the error:

[WARNING] java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/ContextHandler$Context
[WARNING]       at com.google.gwt.dev.codeserver.WebServer.start(WebServer.java:125)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:162)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:104)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:55)
[WARNING] Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.server.handler.ContextHandler$Context
[WARNING]       at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
[WARNING]       at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
[WARNING]       at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
[WARNING]       ... 4 more
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for test 1.0-SNAPSHOT:
[INFO]
[INFO] test ............................................... FAILURE [  4.688 s]
[INFO] test-shared ........................................ SKIPPED
[INFO] test-client ........................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.436 s
[INFO] Finished at: 2026-02-14T09:25:21+11:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal net.ltgt.gwt.maven:gwt-maven-plugin:1.2.0:codeserver (default-cli) on project test: Process exited with an error: 1 (Exit value: 1) -> [Help 1]

Is there a way to allow Spring Boot to use Jetty 12.1.5, but also let the GWT Code Server use Jetty 9.4.58?

(Apologies if this has been asked before, I searched around and couldn't find it)

--
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/1add89dd-49dc-47c0-b3dd-010dc94f1db3n%40googlegroups.com.
Posted by at No comments:

Re: GWT Code Server Jetty Mismatch

That's an irritating outcome for sure - though updating GWT to Jetty 12.1.5 only punts on the issue, since the next time Spring Boot wants a different Jetty version (or some other library) we end up back in this mess (though likely with a much more subtle failure mode).

Gradle does a much better job at letting you break up classpaths here, at the cost of dramatically increased complexity in the worst case - but it could allow you to specify each bom in its own classpath configuration, rather than mix the two together.

I think I have a solution that works for your project, but I'm going to try to reason it out here a bit, so someone can poke holes in my logic:
  • The GWT wiring here is configured for the parent project pom, so that the plugin can run from there if desired. 
  • The server BOM is also declared in the parent project pom, so that we just have it in one place. This probably makes sense for large enough projects where it needs to be reused - but at least for this project it seems unnecessary.
What I did was to move the jetty bom into test-server:
diff --git a/pom.xml b/pom.xml
index bb3edc3..ae118dc 100644
--- a/pom.xml
+++ b/pom.xml
@@ -24,13 +24,6 @@
         <type>pom</type>
         <scope>import</scope>
       </dependency>
-      <dependency>
-        <groupId>org.springframework.boot</groupId>
-        <artifactId>spring-boot-dependencies</artifactId>
-        <version>${spring-boot.version}</version>
-        <type>pom</type>
-        <scope>import</scope>
-      </dependency>
       <dependency>
         <groupId>org.yaml</groupId>
         <artifactId>snakeyaml</artifactId>
diff --git a/test-server/pom.xml b/test-server/pom.xml
index 6dbf708..31426c0 100644
--- a/test-server/pom.xml
+++ b/test-server/pom.xml
@@ -16,6 +16,17 @@
     <maven.compiler.target>17</maven.compiler.target>
   </properties>
 
+  <dependencyManagement>
+    <dependencies>
+      <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-dependencies</artifactId>
+        <version>${spring-boot.version}</version>
+        <type>pom</type>
+        <scope>import</scope>
+      </dependency>
+    </dependencies>
+  </dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>${project.groupId}</groupId>

Then, I was able to build and start the server, and start the devmode server. I did not go so far as to make changes yet, but I'm not familiar with how spring boot likes to work for "dev" mode.

On Friday, February 13, 2026 at 4:55:11 PM UTC-6 ma...@craig-mitchell.com wrote:
I raised a Spring Boot Jetty issue https://github.com/spring-projects/spring-boot/issues/49220 because I thought there was an issue with Jetty.

Turns out, the GWT Code Server is bringing in an old version of Jetty which breaks Spring Boot.

When I tell Spring Boot to use the version of Jetty it wants, the GWT Code Server then breaks with the error:

[WARNING] java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/ContextHandler$Context
[WARNING]       at com.google.gwt.dev.codeserver.WebServer.start(WebServer.java:125)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:162)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:104)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:55)
[WARNING] Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.server.handler.ContextHandler$Context
[WARNING]       at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
[WARNING]       at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
[WARNING]       at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
[WARNING]       ... 4 more
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for test 1.0-SNAPSHOT:
[INFO]
[INFO] test ............................................... FAILURE [  4.688 s]
[INFO] test-shared ........................................ SKIPPED
[INFO] test-client ........................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.436 s
[INFO] Finished at: 2026-02-14T09:25:21+11:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal net.ltgt.gwt.maven:gwt-maven-plugin:1.2.0:codeserver (default-cli) on project test: Process exited with an error: 1 (Exit value: 1) -> [Help 1]

Is there a way to allow Spring Boot to use Jetty 12.1.5, but also let the GWT Code Server use Jetty 9.4.58?

(Apologies if this has been asked before, I searched around and couldn't find it)

--
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/2f128241-5531-4b88-9fb8-c1fa50aac333n%40googlegroups.com.
Posted by at No comments:

Friday, February 13, 2026

GWT Code Server Jetty Mismatch

I raised a Spring Boot Jetty issue https://github.com/spring-projects/spring-boot/issues/49220 because I thought there was an issue with Jetty.

Turns out, the GWT Code Server is bringing in an old version of Jetty which breaks Spring Boot.

When I tell Spring Boot to use the version of Jetty it wants, the GWT Code Server then breaks with the error:

[WARNING] java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/ContextHandler$Context
[WARNING]       at com.google.gwt.dev.codeserver.WebServer.start(WebServer.java:125)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:162)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:104)
[WARNING]       at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:55)
[WARNING] Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.server.handler.ContextHandler$Context
[WARNING]       at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
[WARNING]       at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
[WARNING]       at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
[WARNING]       ... 4 more
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for test 1.0-SNAPSHOT:
[INFO]
[INFO] test ............................................... FAILURE [  4.688 s]
[INFO] test-shared ........................................ SKIPPED
[INFO] test-client ........................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.436 s
[INFO] Finished at: 2026-02-14T09:25:21+11:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal net.ltgt.gwt.maven:gwt-maven-plugin:1.2.0:codeserver (default-cli) on project test: Process exited with an error: 1 (Exit value: 1) -> [Help 1]

Is there a way to allow Spring Boot to use Jetty 12.1.5, but also let the GWT Code Server use Jetty 9.4.58?

(Apologies if this has been asked before, I searched around and couldn't find it)

--
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/08339070-ee36-46d8-8fda-ba995d3c8ae2n%40googlegroups.com.
Posted by at No comments:

Re: Inject nocache.js into the main index.html

Good point Jens.  Here's some handy code that works well for me:

In the HttpServlet that servers up the index.html file:

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
  String serverVersion =  [LOAD YOUR SERVER VERSION]
  String quotedETag = "\"" + serverVersion + "\"";

  response.setHeader("ETag", quotedETag);
  response.setHeader("Cache-Control", "no-cache, must-revalidate");

  String ifNoneMatch = request.getHeader("If-None-Match");

  // The browser has the latest version
  if (quotedETag.equals(ifNoneMatch)) {
    response.setStatus(HttpServletResponse.SC_NOT_MODIFIED); // 304 Not Modified
  }
  // The browser needs the latest version
  else {
    String html = [LOAD YOUR HTML]
    response.setContentType("text/html");
    response.setCharacterEncoding("UTF-8");
    response.getWriter().append(html);
  }
}

You need a serverVersion somehow.  If using Google App Engine, you can do  System.getenv("GAE_VERSION");  otherwise, it's up to you how you get it and make it unique for each deploy.

On Friday, 13 February 2026 at 8:52:48 pm UTC+11 Jens wrote:
Yeah, using the gwt property is the easiest solution. I also use it. But be aware that you now have to update your webserver configuration to tell the browser to not cache the index.html anymore. Otherwise the embedded GWT code will be outdated if you deploy an updated version of your GWT app and all the hashes of *.cache.js files have changed.


-- J.

Craig Mitchell schrieb am Freitag, 13. Februar 2026 um 02:00:28 UTC+1:
Thanks Colin.  Dug around a little and figured out all I needed was:

<meta name="gwt:property" content="baseUrl=/dt/" />

("dt" is my GWT module short name)

Now everything works, including superdevmode.  Ie: No need for the gwtNoCacheJs.contains("superdevmode") check anymore.

I think my page does load a bit faster now (on subsequent times, not the first visit).  https://drift.team/ if anyone is curious what the end result root html source looks like.

On Friday, 13 February 2026 at 10:16:23 am UTC+11 Colin Alworth wrote:
I believe that https://github.com/gwtproject/gwt/blob/main/dev/core/src/com/google/gwt/core/ext/linker/impl/computeScriptBase.js is what you're going to want to read, or possibly replace on your classpath. Alternatively, subclass the CrossSiteIframeLinker to override getJsComputeScriptBase(LinkerContext) to provide your own file.

From that file:
/**
 * Determine our own script's URL by trying various things
 *
 * First - use the baseUrl meta tag if it exists
 * Second - look for a script tag with the src set to MODULE_NAME.nocache.js and
 *   if it's found, use it to determine the baseUrl
 * Third - if the page is not already loaded, try to use some document.write
 *   magic to install a temporary tag and use that to determine the baseUrl.
 *
 * This is included into the selection scripts
 * wherever COMPUTE_SCRIPT_BASE appears with underlines
 * on each side.
 */

The "Second" step is where you appear to be getting stuck - since there is no script tag with a src attr, the rest of the loading code doesn't know what to do. So, add a meta tag for baseUrl so the script knows where the other resources are loaded from.

Note that I haven't messed with this in years, and might have missed a point or two.

On Thursday, February 12, 2026 at 4:54:23 PM UTC-6 ma...@craig-mitchell.com wrote:
I tried to inject the non-dev nocache.js into my main index.html file.  Like this:

String gwtNoCacheJs = loadFileFromServlet("/dt/dt.nocache.js");

if (gwtNoCacheJs.contains("superdevmode")) {
  gwtNoCacheJs = "<script type='text/javascript' src='/dt/dt.nocache.js'></script>";
}
else {
  gwtNoCacheJs = "<script type='text/javascript'>\n" + gwtNoCacheJs + "\n</script>";
}

String html = loadFile("index.html").replace("XXX", gwtNoCacheJs);

However, it doesn't work, as nocache.js wants to load files from the same sub directory it's located in, and not the root directory.

Has anyone done this?  It probably isn't work the effort, as it'll only save one network call, but I was curious if it's 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/9bdf6a9d-8c4a-43a2-bfef-a9fc865090f3n%40googlegroups.com.
Posted by at No comments:

Re: Inject nocache.js into the main index.html

Yeah, using the gwt property is the easiest solution. I also use it. But be aware that you now have to update your webserver configuration to tell the browser to not cache the index.html anymore. Otherwise the embedded GWT code will be outdated if you deploy an updated version of your GWT app and all the hashes of *.cache.js files have changed.


-- J.

Craig Mitchell schrieb am Freitag, 13. Februar 2026 um 02:00:28 UTC+1:
Thanks Colin.  Dug around a little and figured out all I needed was:

<meta name="gwt:property" content="baseUrl=/dt/" />

("dt" is my GWT module short name)

Now everything works, including superdevmode.  Ie: No need for the gwtNoCacheJs.contains("superdevmode") check anymore.

I think my page does load a bit faster now (on subsequent times, not the first visit).  https://drift.team/ if anyone is curious what the end result root html source looks like.

On Friday, 13 February 2026 at 10:16:23 am UTC+11 Colin Alworth wrote:
I believe that https://github.com/gwtproject/gwt/blob/main/dev/core/src/com/google/gwt/core/ext/linker/impl/computeScriptBase.js is what you're going to want to read, or possibly replace on your classpath. Alternatively, subclass the CrossSiteIframeLinker to override getJsComputeScriptBase(LinkerContext) to provide your own file.

From that file:
/**
 * Determine our own script's URL by trying various things
 *
 * First - use the baseUrl meta tag if it exists
 * Second - look for a script tag with the src set to MODULE_NAME.nocache.js and
 *   if it's found, use it to determine the baseUrl
 * Third - if the page is not already loaded, try to use some document.write
 *   magic to install a temporary tag and use that to determine the baseUrl.
 *
 * This is included into the selection scripts
 * wherever COMPUTE_SCRIPT_BASE appears with underlines
 * on each side.
 */

The "Second" step is where you appear to be getting stuck - since there is no script tag with a src attr, the rest of the loading code doesn't know what to do. So, add a meta tag for baseUrl so the script knows where the other resources are loaded from.

Note that I haven't messed with this in years, and might have missed a point or two.

On Thursday, February 12, 2026 at 4:54:23 PM UTC-6 ma...@craig-mitchell.com wrote:
I tried to inject the non-dev nocache.js into my main index.html file.  Like this:

String gwtNoCacheJs = loadFileFromServlet("/dt/dt.nocache.js");

if (gwtNoCacheJs.contains("superdevmode")) {
  gwtNoCacheJs = "<script type='text/javascript' src='/dt/dt.nocache.js'></script>";
}
else {
  gwtNoCacheJs = "<script type='text/javascript'>\n" + gwtNoCacheJs + "\n</script>";
}

String html = loadFile("index.html").replace("XXX", gwtNoCacheJs);

However, it doesn't work, as nocache.js wants to load files from the same sub directory it's located in, and not the root directory.

Has anyone done this?  It probably isn't work the effort, as it'll only save one network call, but I was curious if it's 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/9e8f90ca-9e51-4c1e-9642-4e0cdadb2a79n%40googlegroups.com.
Posted by at No comments:

Thursday, February 12, 2026

Re: Inject nocache.js into the main index.html

I should point out, this is only useful if you have a single page app.  If you load different html pages, don't do this, as you'll be reloading the nocache.js for each page.

On Friday, 13 February 2026 at 12:00:28 pm UTC+11 Craig Mitchell wrote:
Thanks Colin.  Dug around a little and figured out all I needed was:

<meta name="gwt:property" content="baseUrl=/dt/" />

("dt" is my GWT module short name)

Now everything works, including superdevmode.  Ie: No need for the gwtNoCacheJs.contains("superdevmode") check anymore.

I think my page does load a bit faster now (on subsequent times, not the first visit).  https://drift.team/ if anyone is curious what the end result root html source looks like.

On Friday, 13 February 2026 at 10:16:23 am UTC+11 Colin Alworth wrote:
I believe that https://github.com/gwtproject/gwt/blob/main/dev/core/src/com/google/gwt/core/ext/linker/impl/computeScriptBase.js is what you're going to want to read, or possibly replace on your classpath. Alternatively, subclass the CrossSiteIframeLinker to override getJsComputeScriptBase(LinkerContext) to provide your own file.

From that file:
/**
 * Determine our own script's URL by trying various things
 *
 * First - use the baseUrl meta tag if it exists
 * Second - look for a script tag with the src set to MODULE_NAME.nocache.js and
 *   if it's found, use it to determine the baseUrl
 * Third - if the page is not already loaded, try to use some document.write
 *   magic to install a temporary tag and use that to determine the baseUrl.
 *
 * This is included into the selection scripts
 * wherever COMPUTE_SCRIPT_BASE appears with underlines
 * on each side.
 */

The "Second" step is where you appear to be getting stuck - since there is no script tag with a src attr, the rest of the loading code doesn't know what to do. So, add a meta tag for baseUrl so the script knows where the other resources are loaded from.

Note that I haven't messed with this in years, and might have missed a point or two.

On Thursday, February 12, 2026 at 4:54:23 PM UTC-6 ma...@craig-mitchell.com wrote:
I tried to inject the non-dev nocache.js into my main index.html file.  Like this:

String gwtNoCacheJs = loadFileFromServlet("/dt/dt.nocache.js");

if (gwtNoCacheJs.contains("superdevmode")) {
  gwtNoCacheJs = "<script type='text/javascript' src='/dt/dt.nocache.js'></script>";
}
else {
  gwtNoCacheJs = "<script type='text/javascript'>\n" + gwtNoCacheJs + "\n</script>";
}

String html = loadFile("index.html").replace("XXX", gwtNoCacheJs);

However, it doesn't work, as nocache.js wants to load files from the same sub directory it's located in, and not the root directory.

Has anyone done this?  It probably isn't work the effort, as it'll only save one network call, but I was curious if it's 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/f935eef0-0bb9-4802-b6d0-31e73f8996b2n%40googlegroups.com.
Posted by at No comments:

Re: Inject nocache.js into the main index.html

Thanks Colin.  Dug around a little and figured out all I needed was:

<meta name="gwt:property" content="baseUrl=/dt/" />

("dt" is my GWT module short name)

Now everything works, including superdevmode.  Ie: No need for the gwtNoCacheJs.contains("superdevmode") check anymore.

I think my page does load a bit faster now (on subsequent times, not the first visit).  https://drift.team/ if anyone is curious what the end result root html source looks like.

On Friday, 13 February 2026 at 10:16:23 am UTC+11 Colin Alworth wrote:
I believe that https://github.com/gwtproject/gwt/blob/main/dev/core/src/com/google/gwt/core/ext/linker/impl/computeScriptBase.js is what you're going to want to read, or possibly replace on your classpath. Alternatively, subclass the CrossSiteIframeLinker to override getJsComputeScriptBase(LinkerContext) to provide your own file.

From that file:
/**
 * Determine our own script's URL by trying various things
 *
 * First - use the baseUrl meta tag if it exists
 * Second - look for a script tag with the src set to MODULE_NAME.nocache.js and
 *   if it's found, use it to determine the baseUrl
 * Third - if the page is not already loaded, try to use some document.write
 *   magic to install a temporary tag and use that to determine the baseUrl.
 *
 * This is included into the selection scripts
 * wherever COMPUTE_SCRIPT_BASE appears with underlines
 * on each side.
 */

The "Second" step is where you appear to be getting stuck - since there is no script tag with a src attr, the rest of the loading code doesn't know what to do. So, add a meta tag for baseUrl so the script knows where the other resources are loaded from.

Note that I haven't messed with this in years, and might have missed a point or two.

On Thursday, February 12, 2026 at 4:54:23 PM UTC-6 ma...@craig-mitchell.com wrote:
I tried to inject the non-dev nocache.js into my main index.html file.  Like this:

String gwtNoCacheJs = loadFileFromServlet("/dt/dt.nocache.js");

if (gwtNoCacheJs.contains("superdevmode")) {
  gwtNoCacheJs = "<script type='text/javascript' src='/dt/dt.nocache.js'></script>";
}
else {
  gwtNoCacheJs = "<script type='text/javascript'>\n" + gwtNoCacheJs + "\n</script>";
}

String html = loadFile("index.html").replace("XXX", gwtNoCacheJs);

However, it doesn't work, as nocache.js wants to load files from the same sub directory it's located in, and not the root directory.

Has anyone done this?  It probably isn't work the effort, as it'll only save one network call, but I was curious if it's 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/a77a4ea3-c4ed-48b8-bd3e-c3877109fd6bn%40googlegroups.com.
Posted by at No comments:

Re: Inject nocache.js into the main index.html

I believe that https://github.com/gwtproject/gwt/blob/main/dev/core/src/com/google/gwt/core/ext/linker/impl/computeScriptBase.js is what you're going to want to read, or possibly replace on your classpath. Alternatively, subclass the CrossSiteIframeLinker to override getJsComputeScriptBase(LinkerContext) to provide your own file.

From that file:
/**
 * Determine our own script's URL by trying various things
 *
 * First - use the baseUrl meta tag if it exists
 * Second - look for a script tag with the src set to MODULE_NAME.nocache.js and
 *   if it's found, use it to determine the baseUrl
 * Third - if the page is not already loaded, try to use some document.write
 *   magic to install a temporary tag and use that to determine the baseUrl.
 *
 * This is included into the selection scripts
 * wherever COMPUTE_SCRIPT_BASE appears with underlines
 * on each side.
 */

The "Second" step is where you appear to be getting stuck - since there is no script tag with a src attr, the rest of the loading code doesn't know what to do. So, add a meta tag for baseUrl so the script knows where the other resources are loaded from.

Note that I haven't messed with this in years, and might have missed a point or two.

On Thursday, February 12, 2026 at 4:54:23 PM UTC-6 ma...@craig-mitchell.com wrote:
I tried to inject the non-dev nocache.js into my main index.html file.  Like this:

String gwtNoCacheJs = loadFileFromServlet("/dt/dt.nocache.js");

if (gwtNoCacheJs.contains("superdevmode")) {
  gwtNoCacheJs = "<script type='text/javascript' src='/dt/dt.nocache.js'></script>";
}
else {
  gwtNoCacheJs = "<script type='text/javascript'>\n" + gwtNoCacheJs + "\n</script>";
}

String html = loadFile("index.html").replace("XXX", gwtNoCacheJs);

However, it doesn't work, as nocache.js wants to load files from the same sub directory it's located in, and not the root directory.

Has anyone done this?  It probably isn't work the effort, as it'll only save one network call, but I was curious if it's 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/9bbe0509-b98f-42e3-84f5-65cbc3e18d29n%40googlegroups.com.
Posted by at No comments:

Inject nocache.js into the main index.html

I tried to inject the non-dev nocache.js into my main index.html file.  Like this:

String gwtNoCacheJs = loadFileFromServlet("/dt/dt.nocache.js");

if (gwtNoCacheJs.contains("superdevmode")) {
  gwtNoCacheJs = "<script type='text/javascript' src='/dt/dt.nocache.js'></script>";
}
else {
  gwtNoCacheJs = "<script type='text/javascript'>\n" + gwtNoCacheJs + "\n</script>";
}

String html = loadFile("index.html").replace("XXX", gwtNoCacheJs);

However, it doesn't work, as nocache.js wants to load files from the same sub directory it's located in, and not the root directory.

Has anyone done this?  It probably isn't work the effort, as it'll only save one network call, but I was curious if it's 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/eaead646-7b11-4c83-81b7-508623eaed02n%40googlegroups.com.
Posted by at No comments:

Re: GWT 2.13 released

Wow, looks like a significant update. Thanks, Colin! Initial testing looks good here; everything builds with no issues.

On Wednesday, February 11, 2026 at 11:54:10 AM UTC-8 Colin Alworth wrote:
GWT 2.13 has been released! It is available from our releases page as a SDK zip, or from Maven Central in the usual manner.

Highlights from the release notes:
  • Removed more old polyfills and IE-specific workarounds
  • Samples updated to use Maven, usually as multi-module projects
  • 2.13 is likely to be the last release where the compiler and dev tools run on Java 11. Java 8 server support is not explicitly tested any more, we no longer seem to have any interest in this (or at least no one volunteering for the release testing or other maintenance work)
  • DevMode server defaults to only serving static files - projects that wish to use the old Jetty 9 launcher may specify -server com.google.gwt.dev.shell.JettyLauncher, but this is due to be removed. Projects should either split their server/client classpath, or switch to a ServletContainerLauncher that runs another server (https://github.com/niloc132/gwt-devmode-server-sample is an example project that can provide this)
  • Support -strict in test arguments, to more easily find compile issues in GWT libraries
  • JFR events added to replace SpeedTracer, support observability into compiler steps, permutation and fragment counts, and output size. Additionally, the gwt.jjs.dumpAst system property has been tweaked to support filtering, and generate more readable output
  • jaxb and xml-apis are now optional when using GWT's javax.validation support, set the gwt.validation.ignoreXml system property to avoid needing these
  • Improved JRE emulation tracking, listing not only supported APIs, but also document unsupported APIs with links to issues

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

This has been a longer release cycle than we are happy with, so thank you for everyone's patience with this. Much of my own work that delayed the release will hopefully pay off for the next one - there are better tools to track what work the compiler is changing and how it is working, and more unused classes have been deprecated or removed as appropriate to enable future work to change our build system away from Ant. Other contributors made excellent use of this extra time - the list of JRE enhancements is especially impressive, the most classes updated since 2.9.0, which took far longer to produce.

There is a known issue that may impact Windows users when running DevMode or CodeServer, tracked as https://github.com/gwtproject/gwt/issues/10272. If you experience this, please do leave a note with any details about your environment - we have a candidate fix, but as most Windows testers are _not_ impacted by it, there is concern that the problem might not be fully understood or the fix incomplete.

Special thanks to our testers over the last week for validating the release on a variety of OSes, Java versions, browsers, and IDEs.

--
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/e78c47ea-c6ae-4203-8de4-5b43a6045740n%40googlegroups.com.
Posted by at No comments:

Re: GWT 2.13 released

Works fine for me too!

On Thu, Feb 12, 2026 at 11:54 AM Filipe Sousa <natros@gmail.com> wrote:
🥳

On Wed, Feb 11, 2026 at 7:54 PM Colin Alworth <colin@colinalworth.com> wrote:
GWT 2.13 has been released! It is available from our releases page as a SDK zip, or from Maven Central in the usual manner.

Highlights from the release notes:
  • Removed more old polyfills and IE-specific workarounds
  • Samples updated to use Maven, usually as multi-module projects
  • 2.13 is likely to be the last release where the compiler and dev tools run on Java 11. Java 8 server support is not explicitly tested any more, we no longer seem to have any interest in this (or at least no one volunteering for the release testing or other maintenance work)
  • DevMode server defaults to only serving static files - projects that wish to use the old Jetty 9 launcher may specify -server com.google.gwt.dev.shell.JettyLauncher, but this is due to be removed. Projects should either split their server/client classpath, or switch to a ServletContainerLauncher that runs another server (https://github.com/niloc132/gwt-devmode-server-sample is an example project that can provide this)
  • Support -strict in test arguments, to more easily find compile issues in GWT libraries
  • JFR events added to replace SpeedTracer, support observability into compiler steps, permutation and fragment counts, and output size. Additionally, the gwt.jjs.dumpAst system property has been tweaked to support filtering, and generate more readable output
  • jaxb and xml-apis are now optional when using GWT's javax.validation support, set the gwt.validation.ignoreXml system property to avoid needing these
  • Improved JRE emulation tracking, listing not only supported APIs, but also document unsupported APIs with links to issues

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

This has been a longer release cycle than we are happy with, so thank you for everyone's patience with this. Much of my own work that delayed the release will hopefully pay off for the next one - there are better tools to track what work the compiler is changing and how it is working, and more unused classes have been deprecated or removed as appropriate to enable future work to change our build system away from Ant. Other contributors made excellent use of this extra time - the list of JRE enhancements is especially impressive, the most classes updated since 2.9.0, which took far longer to produce.

There is a known issue that may impact Windows users when running DevMode or CodeServer, tracked as https://github.com/gwtproject/gwt/issues/10272. If you experience this, please do leave a note with any details about your environment - we have a candidate fix, but as most Windows testers are _not_ impacted by it, there is concern that the problem might not be fully understood or the fix incomplete.

Special thanks to our testers over the last week for validating the release on a variety of OSes, Java versions, browsers, and IDEs.

--
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/abdb12ba-7f1f-4fc5-bfce-3bec851f48dfn%40googlegroups.com.


--
Filipe Sousa

--
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/CAFrD1RLZp-F0QCcRsrr%3D5D8MiH3kL55t0G99VA0oDXsNtPyudQ%40mail.gmail.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%2BkiFsdsesPEGPfvqWYiTwU5LgMvARZS%2Bk3X84RBzNsBoh22UA%40mail.gmail.com.
Posted by at No comments:

Re: GWT 2.13 released

🥳

On Wed, Feb 11, 2026 at 7:54 PM Colin Alworth <colin@colinalworth.com> wrote:
GWT 2.13 has been released! It is available from our releases page as a SDK zip, or from Maven Central in the usual manner.

Highlights from the release notes:
  • Removed more old polyfills and IE-specific workarounds
  • Samples updated to use Maven, usually as multi-module projects
  • 2.13 is likely to be the last release where the compiler and dev tools run on Java 11. Java 8 server support is not explicitly tested any more, we no longer seem to have any interest in this (or at least no one volunteering for the release testing or other maintenance work)
  • DevMode server defaults to only serving static files - projects that wish to use the old Jetty 9 launcher may specify -server com.google.gwt.dev.shell.JettyLauncher, but this is due to be removed. Projects should either split their server/client classpath, or switch to a ServletContainerLauncher that runs another server (https://github.com/niloc132/gwt-devmode-server-sample is an example project that can provide this)
  • Support -strict in test arguments, to more easily find compile issues in GWT libraries
  • JFR events added to replace SpeedTracer, support observability into compiler steps, permutation and fragment counts, and output size. Additionally, the gwt.jjs.dumpAst system property has been tweaked to support filtering, and generate more readable output
  • jaxb and xml-apis are now optional when using GWT's javax.validation support, set the gwt.validation.ignoreXml system property to avoid needing these
  • Improved JRE emulation tracking, listing not only supported APIs, but also document unsupported APIs with links to issues

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

This has been a longer release cycle than we are happy with, so thank you for everyone's patience with this. Much of my own work that delayed the release will hopefully pay off for the next one - there are better tools to track what work the compiler is changing and how it is working, and more unused classes have been deprecated or removed as appropriate to enable future work to change our build system away from Ant. Other contributors made excellent use of this extra time - the list of JRE enhancements is especially impressive, the most classes updated since 2.9.0, which took far longer to produce.

There is a known issue that may impact Windows users when running DevMode or CodeServer, tracked as https://github.com/gwtproject/gwt/issues/10272. If you experience this, please do leave a note with any details about your environment - we have a candidate fix, but as most Windows testers are _not_ impacted by it, there is concern that the problem might not be fully understood or the fix incomplete.

Special thanks to our testers over the last week for validating the release on a variety of OSes, Java versions, browsers, and IDEs.

--
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/abdb12ba-7f1f-4fc5-bfce-3bec851f48dfn%40googlegroups.com.


--
Filipe Sousa

--
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/CAFrD1RLZp-F0QCcRsrr%3D5D8MiH3kL55t0G99VA0oDXsNtPyudQ%40mail.gmail.com.
Posted by at No comments:

gwt-maven-springboot-archetype v2026.2.12 & Nalu v4.0.2 released

Hi,
following the GWT 2.13.0 release, Nalu & the gwt-maven-springboot-archetype are updated.

* Nalu 4.0.2 now uses GWT 2.13.0. (In case you do not use one of the Nalu GWT-plguins, the release has no impact.)
* gwt-maven-springboot-archetype now creates archetypes using SpringBoot 4, GWT 2.13.0 & Java 17

--
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/af1c4990-d26e-48ce-b54d-8b38949b808bn%40googlegroups.com.
Posted by at No comments:

Re: GWT 2.13 released

it works fine on my project also! 
many thanks Pochette surprisePochette surprisePochette surprisePochette surprisePochette surprisePochette surprisePochette surprisePochette surprise


Le mercredi 11 février 2026 à 20:54:10 UTC+1, Colin Alworth a écrit :
GWT 2.13 has been released! It is available from our releases page as a SDK zip, or from Maven Central in the usual manner.

Highlights from the release notes:
  • Removed more old polyfills and IE-specific workarounds
  • Samples updated to use Maven, usually as multi-module projects
  • 2.13 is likely to be the last release where the compiler and dev tools run on Java 11. Java 8 server support is not explicitly tested any more, we no longer seem to have any interest in this (or at least no one volunteering for the release testing or other maintenance work)
  • DevMode server defaults to only serving static files - projects that wish to use the old Jetty 9 launcher may specify -server com.google.gwt.dev.shell.JettyLauncher, but this is due to be removed. Projects should either split their server/client classpath, or switch to a ServletContainerLauncher that runs another server (https://github.com/niloc132/gwt-devmode-server-sample is an example project that can provide this)
  • Support -strict in test arguments, to more easily find compile issues in GWT libraries
  • JFR events added to replace SpeedTracer, support observability into compiler steps, permutation and fragment counts, and output size. Additionally, the gwt.jjs.dumpAst system property has been tweaked to support filtering, and generate more readable output
  • jaxb and xml-apis are now optional when using GWT's javax.validation support, set the gwt.validation.ignoreXml system property to avoid needing these
  • Improved JRE emulation tracking, listing not only supported APIs, but also document unsupported APIs with links to issues

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

This has been a longer release cycle than we are happy with, so thank you for everyone's patience with this. Much of my own work that delayed the release will hopefully pay off for the next one - there are better tools to track what work the compiler is changing and how it is working, and more unused classes have been deprecated or removed as appropriate to enable future work to change our build system away from Ant. Other contributors made excellent use of this extra time - the list of JRE enhancements is especially impressive, the most classes updated since 2.9.0, which took far longer to produce.

There is a known issue that may impact Windows users when running DevMode or CodeServer, tracked as https://github.com/gwtproject/gwt/issues/10272. If you experience this, please do leave a note with any details about your environment - we have a candidate fix, but as most Windows testers are _not_ impacted by it, there is concern that the problem might not be fully understood or the fix incomplete.

Special thanks to our testers over the last week for validating the release on a variety of OSes, Java versions, browsers, and IDEs.

--
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/9938a7bf-2b6a-439c-9409-e77cda0eb471n%40googlegroups.com.
Posted by at No comments:
Subscribe to: Comments (Atom)