Re: Temp gwt directory

You can relocate the persistent unit cache dir with the gwt.persistentunitcachedir system property, so with the maven plugin:

<systemProperties>
  <gwt.persistentunitcachedir>${project.build.directory}/gwt/unitCache/</gwt.persistentunitcachedir>
</systemProperties>

https://github.com/gwtproject/gwt/blob/9940b0200d57ff83ff0a1c43bac4674e5c56b5d1/dev/core/src/com/google/gwt/dev/javac/UnitCacheSingleton.java#L90

But note that the default location is as a sibling of the output directory for the GWT Compiler (https://github.com/gwtproject/gwt/blob/9940b0200d57ff83ff0a1c43bac4674e5c56b5d1/dev/core/src/com/google/gwt/dev/Compiler.java#L80), and only for the CodeServer is it inside the temporary directory (https://github.com/gwtproject/gwt/blob/main/dev/core/src/com/google/gwt/dev/util/DiskCachingUtil.java).
This might affect how/where you want to configure this, to possibly only change the gwt:codeserver behavior without changing the gwt:compile's one.

…and you can disable the persistent unit cache with gwt.persistentunitcache=false

On Saturday, September 26, 2026 at 2:59:52 AM UTC+2 ma...@craig-mitchell.com wrote:

If I set the tmp directory to just  <java.io.tmpdir>${project.build.directory}</java.io.tmpdir>  then I don't need to get Maven to create it.  The target direcory is spammed with a mass of GWT files, but at least it works.

On Saturday, 26 September 2026 at 10:44:32 am UTC+10 Craig Mitchell wrote:

This bug was doing my head in:  https://github.com/gwtproject/gwt/issues/10329 (because I'm moving widgets in and out of GWT, and when I switch between my git branches, I hit it).

However, I figured out that GWT writes to the windows temp dir %temp%/gwt-cache-xxx/gwt-unitCache and if I delete that, the problem goes away.

I thought it was the tbroyer gwt-maven-plugin creating these temp files, but it wasn't, it's some internal GWT thing.

I managed to relocate the files in the tbroyer plugin configuration with:

<systemProperties>
  <java.io.tmpdir>${project.build.directory}/gwt-temp</java.io.tmpdir>
</systemProperties>

Now a simple mvn clean gets rid of them.  However, GWT won't create this directory automatically, so when you try to run after a clean, you get:

[WARNING] java.lang.ExceptionInInitializerError
[WARNING] at com.google.gwt.dev.javac.CompiledClass.<clinit>(CompiledClass.java:42)
[WARNING] at com.google.gwt.dev.javac.JdtCompiler$CompilerImpl.createCompiledClass(JdtCompiler.java:352)
[WARNING] at com.google.gwt.dev.javac.JdtCompiler$CompilerImpl.process(JdtCompiler.java:315)
[WARNING] at org.eclipse.jdt.internal.compiler.Compiler.processCompiledUnits(Compiler.java:575)
[WARNING] at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:475)
[WARNING] at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:426)
[WARNING] at com.google.gwt.dev.javac.JdtCompiler.doCompile(JdtCompiler.java:1059)
[WARNING] at com.google.gwt.dev.javac.CompilationStateBuilder$CompileMoreLater.compile(CompilationStateBuilder.java:314)
[WARNING] at com.google.gwt.dev.javac.CompilationStateBuilder.doBuildFrom(CompilationStateBuilder.java:519)
[WARNING] at com.google.gwt.dev.javac.CompilationStateBuilder.buildFrom(CompilationStateBuilder.java:453)
[WARNING] at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:425)
[WARNING] at com.google.gwt.dev.codeserver.Recompiler.initWithoutPrecompile(Recompiler.java:221)
[WARNING] at com.google.gwt.dev.codeserver.Outbox.maybePrecompile(Outbox.java:89)
[WARNING] at com.google.gwt.dev.codeserver.Outbox.<init>(Outbox.java:61)
[WARNING] at com.google.gwt.dev.codeserver.CodeServer.makeOutboxTable(CodeServer.java:194)
[WARNING] at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:153)
[WARNING] at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:106)
[WARNING] at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:57)
[WARNING] Caused by: java.lang.RuntimeException: Unable to initialize byte cache
[WARNING] at com.google.gwt.dev.util.DiskCache.<init>(DiskCache.java:78)
[WARNING] at com.google.gwt.dev.util.DiskCache.<clinit>(DiskCache.java:65)
[WARNING] ... 18 more
[WARNING] Caused by: java.io.IOException: The system cannot find the path specified
[WARNING] at java.base/java.io.WinNTFileSystem.createFileExclusively0(Native Method)
[WARNING] at java.base/java.io.WinNTFileSystem.createFileExclusively(WinNTFileSystem.java:542)
[WARNING] at java.base/java.io.File.createTempFile(File.java:1887)
[WARNING] at java.base/java.io.File.createTempFile(File.java:1928)
[WARNING] at com.google.gwt.dev.util.DiskCache.<init>(DiskCache.java:72)
[WARNING] ... 19 more

This can be fixed by getting maven to create the directory:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-antrun-plugin</artifactId>
  <version>3.2.0</version>

  <executions>
    <execution>
      <id>create-gwt-temp</id>
      <phase>initialize</phase>
      <configuration>
        <target>
          <mkdir dir="${project.build.directory}/gwt-temp"/>
        </target>
      </configuration>
      <goals>
        <goal>run</goal>
      </goals>
    </execution>
  </executions>
</plugin>

I feel like there is a better way to manage the GWT temp directory.  Does anyone have a better solution?  Thanks.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/97fb0dbb-510f-4028-b360-8b9ddb3617b0n%40googlegroups.com.

Re: Temp gwt directory

If I set the tmp directory to just  <java.io.tmpdir>${project.build.directory}</java.io.tmpdir>  then I don't need to get Maven to create it.  The target direcory is spammed with a mass of GWT files, but at least it works.

On Saturday, 26 September 2026 at 10:44:32 am UTC+10 Craig Mitchell wrote:

This bug was doing my head in:  https://github.com/gwtproject/gwt/issues/10329 (because I'm moving widgets in and out of GWT, and when I switch between my git branches, I hit it).

However, I figured out that GWT writes to the windows temp dir %temp%/gwt-cache-xxx/gwt-unitCache and if I delete that, the problem goes away.

I thought it was the tbroyer gwt-maven-plugin creating these temp files, but it wasn't, it's some internal GWT thing.

I managed to relocate the files in the tbroyer plugin configuration with:

<systemProperties>
  <java.io.tmpdir>${project.build.directory}/gwt-temp</java.io.tmpdir>
</systemProperties>

Now a simple mvn clean gets rid of them.  However, GWT won't create this directory automatically, so when you try to run after a clean, you get:

[WARNING] java.lang.ExceptionInInitializerError
[WARNING] at com.google.gwt.dev.javac.CompiledClass.<clinit>(CompiledClass.java:42)
[WARNING] at com.google.gwt.dev.javac.JdtCompiler$CompilerImpl.createCompiledClass(JdtCompiler.java:352)
[WARNING] at com.google.gwt.dev.javac.JdtCompiler$CompilerImpl.process(JdtCompiler.java:315)
[WARNING] at org.eclipse.jdt.internal.compiler.Compiler.processCompiledUnits(Compiler.java:575)
[WARNING] at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:475)
[WARNING] at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:426)
[WARNING] at com.google.gwt.dev.javac.JdtCompiler.doCompile(JdtCompiler.java:1059)
[WARNING] at com.google.gwt.dev.javac.CompilationStateBuilder$CompileMoreLater.compile(CompilationStateBuilder.java:314)
[WARNING] at com.google.gwt.dev.javac.CompilationStateBuilder.doBuildFrom(CompilationStateBuilder.java:519)
[WARNING] at com.google.gwt.dev.javac.CompilationStateBuilder.buildFrom(CompilationStateBuilder.java:453)
[WARNING] at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:425)
[WARNING] at com.google.gwt.dev.codeserver.Recompiler.initWithoutPrecompile(Recompiler.java:221)
[WARNING] at com.google.gwt.dev.codeserver.Outbox.maybePrecompile(Outbox.java:89)
[WARNING] at com.google.gwt.dev.codeserver.Outbox.<init>(Outbox.java:61)
[WARNING] at com.google.gwt.dev.codeserver.CodeServer.makeOutboxTable(CodeServer.java:194)
[WARNING] at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:153)
[WARNING] at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:106)
[WARNING] at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:57)
[WARNING] Caused by: java.lang.RuntimeException: Unable to initialize byte cache
[WARNING] at com.google.gwt.dev.util.DiskCache.<init>(DiskCache.java:78)
[WARNING] at com.google.gwt.dev.util.DiskCache.<clinit>(DiskCache.java:65)
[WARNING] ... 18 more
[WARNING] Caused by: java.io.IOException: The system cannot find the path specified
[WARNING] at java.base/java.io.WinNTFileSystem.createFileExclusively0(Native Method)
[WARNING] at java.base/java.io.WinNTFileSystem.createFileExclusively(WinNTFileSystem.java:542)
[WARNING] at java.base/java.io.File.createTempFile(File.java:1887)
[WARNING] at java.base/java.io.File.createTempFile(File.java:1928)
[WARNING] at com.google.gwt.dev.util.DiskCache.<init>(DiskCache.java:72)
[WARNING] ... 19 more

This can be fixed by getting maven to create the directory:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-antrun-plugin</artifactId>
  <version>3.2.0</version>

  <executions>
    <execution>
      <id>create-gwt-temp</id>
      <phase>initialize</phase>
      <configuration>
        <target>
          <mkdir dir="${project.build.directory}/gwt-temp"/>
        </target>
      </configuration>
      <goals>
        <goal>run</goal>
      </goals>
    </execution>
  </executions>
</plugin>

I feel like there is a better way to manage the GWT temp directory.  Does anyone have a better solution?  Thanks.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/57006d9f-0ccd-4026-b551-c96b5cd08e23n%40googlegroups.com.

Temp gwt directory

This bug was doing my head in:  https://github.com/gwtproject/gwt/issues/10329 (because I'm moving widgets in and out of GWT, and when I switch between my git branches, I hit it).

However, I figured out that GWT writes to the windows temp dir %temp%/gwt-cache-xxx/gwt-unitCache and if I delete that, the problem goes away.

I thought it was the tbroyer gwt-maven-plugin creating these temp files, but it wasn't, it's some internal GWT thing.

I managed to relocate the files in the tbroyer plugin configuration with:

<systemProperties>
  <java.io.tmpdir>${project.build.directory}/gwt-temp</java.io.tmpdir>
</systemProperties>

Now a simple mvn clean gets rid of them.  However, GWT won't create this directory automatically, so when you try to run after a clean, you get:

[WARNING] java.lang.ExceptionInInitializerError
[WARNING] at com.google.gwt.dev.javac.CompiledClass.<clinit>(CompiledClass.java:42)
[WARNING] at com.google.gwt.dev.javac.JdtCompiler$CompilerImpl.createCompiledClass(JdtCompiler.java:352)
[WARNING] at com.google.gwt.dev.javac.JdtCompiler$CompilerImpl.process(JdtCompiler.java:315)
[WARNING] at org.eclipse.jdt.internal.compiler.Compiler.processCompiledUnits(Compiler.java:575)
[WARNING] at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:475)
[WARNING] at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:426)
[WARNING] at com.google.gwt.dev.javac.JdtCompiler.doCompile(JdtCompiler.java:1059)
[WARNING] at com.google.gwt.dev.javac.CompilationStateBuilder$CompileMoreLater.compile(CompilationStateBuilder.java:314)
[WARNING] at com.google.gwt.dev.javac.CompilationStateBuilder.doBuildFrom(CompilationStateBuilder.java:519)
[WARNING] at com.google.gwt.dev.javac.CompilationStateBuilder.buildFrom(CompilationStateBuilder.java:453)
[WARNING] at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:425)
[WARNING] at com.google.gwt.dev.codeserver.Recompiler.initWithoutPrecompile(Recompiler.java:221)
[WARNING] at com.google.gwt.dev.codeserver.Outbox.maybePrecompile(Outbox.java:89)
[WARNING] at com.google.gwt.dev.codeserver.Outbox.<init>(Outbox.java:61)
[WARNING] at com.google.gwt.dev.codeserver.CodeServer.makeOutboxTable(CodeServer.java:194)
[WARNING] at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:153)
[WARNING] at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:106)
[WARNING] at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:57)
[WARNING] Caused by: java.lang.RuntimeException: Unable to initialize byte cache
[WARNING] at com.google.gwt.dev.util.DiskCache.<init>(DiskCache.java:78)
[WARNING] at com.google.gwt.dev.util.DiskCache.<clinit>(DiskCache.java:65)
[WARNING] ... 18 more
[WARNING] Caused by: java.io.IOException: The system cannot find the path specified
[WARNING] at java.base/java.io.WinNTFileSystem.createFileExclusively0(Native Method)
[WARNING] at java.base/java.io.WinNTFileSystem.createFileExclusively(WinNTFileSystem.java:542)
[WARNING] at java.base/java.io.File.createTempFile(File.java:1887)
[WARNING] at java.base/java.io.File.createTempFile(File.java:1928)
[WARNING] at com.google.gwt.dev.util.DiskCache.<init>(DiskCache.java:72)
[WARNING] ... 19 more

This can be fixed by getting maven to create the directory:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-antrun-plugin</artifactId>
  <version>3.2.0</version>

  <executions>
    <execution>
      <id>create-gwt-temp</id>
      <phase>initialize</phase>
      <configuration>
        <target>
          <mkdir dir="${project.build.directory}/gwt-temp"/>
        </target>
      </configuration>
      <goals>
        <goal>run</goal>
      </goals>
    </execution>
  </executions>
</plugin>

I feel like there is a better way to manage the GWT temp directory.  Does anyone have a better solution?  Thanks.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/6b2ff6d6-7162-4c95-a2bc-53bb4c16c926n%40googlegroups.com.

Re: GWt TeaVM comparison

I compile to JavaScript, I guess if I was compiling to WASM I wouldn't have the source map problems, no WASM code for it to keep stepping into. Other than that, I think I read WASM is used a lot for things like offloading web scraping to distributed devices,  but presumably where there's very demanding processing it's  more efficient. I do a lot of D3 in TS, I presume WASM can bridge to that so it's worth considering 

Yahoo Mail: Search, Organize, Conquer

On Fri, Sep 4, 2026 at 4:49 AM, Craig Mitchell

<mail@craig-mitchell.com> wrote:

I looked at GraalVM as a JVM replacement, but it wouldn't work with the libraries I use (Google Datastore mainly).  I didn't realise it could also be used to compile WebAssembly.  Thanks, will check it out!

Will also check out J2CL for Web Assembly.  Publish the plugin!  :-D

On Friday, 4 September 2026 at 1:36:53 pm UTC+10 Dmitrii Tikhomirov wrote:

You can use GraalVM to compile Java to WebAssembly.

 The main limitation is multithreading; almost everything else works. 

If you need a very small WASM binary, you can use J2CL. 

I’ve actually already added WASM support to the j2cl-maven-plugin, but I still haven’t gotten around to publishing it.

On Sep 3, 2026, at 8:31 PM, Craig Mitchell <ma...@craig-mitchell.com> wrote:

Do you use it to compile to JavaScript or WebAssembly?

I'd love to compile Java to WebAssembly, but I'm too nervous about the edge cases.

On Friday, 4 September 2026 at 7:43:09 am UTC+10 Tim Macpherson wrote:

Maybe interesting for some:

.

I'm using TeaVM. Main problem is source map debugging will  usually descend into transpiled js, GWT doesn't have that problem otherwise ok it it lasts.

Yahoo Mail: Search, Organize, Conquer

--
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/9335d428-ddc6-4f79-b180-07f733051f05n%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/87aaa65a-857e-410e-9f7a-03c9720ddbecn%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/130306843.1321063.1788552339412%40mail.yahoo.com.

Re: GWt TeaVM comparison

I looked at GraalVM as a JVM replacement, but it wouldn't work with the libraries I use (Google Datastore mainly).  I didn't realise it could also be used to compile WebAssembly.  Thanks, will check it out!

Will also check out J2CL for Web Assembly.  Publish the plugin!  :-D

On Friday, 4 September 2026 at 1:36:53 pm UTC+10 Dmitrii Tikhomirov wrote:

You can use GraalVM to compile Java to WebAssembly.

 The main limitation is multithreading; almost everything else works. 

If you need a very small WASM binary, you can use J2CL. 

I’ve actually already added WASM support to the j2cl-maven-plugin, but I still haven’t gotten around to publishing it.

On Sep 3, 2026, at 8:31 PM, Craig Mitchell <ma...@craig-mitchell.com> wrote:

Do you use it to compile to JavaScript or WebAssembly?

I'd love to compile Java to WebAssembly, but I'm too nervous about the edge cases.

On Friday, 4 September 2026 at 7:43:09 am UTC+10 Tim Macpherson wrote:

Maybe interesting for some:

.

I'm using TeaVM. Main problem is source map debugging will  usually descend into transpiled js, GWT doesn't have that problem otherwise ok it it lasts.

Yahoo Mail: Search, Organize, Conquer

--
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/9335d428-ddc6-4f79-b180-07f733051f05n%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/87aaa65a-857e-410e-9f7a-03c9720ddbecn%40googlegroups.com.

Re: GWt TeaVM comparison

You can use GraalVM to compile Java to WebAssembly.

 The main limitation is multithreading; almost everything else works. 

If you need a very small WASM binary, you can use J2CL. 

I’ve actually already added WASM support to the j2cl-maven-plugin, but I still haven’t gotten around to publishing it.

On Sep 3, 2026, at 8:31 PM, Craig Mitchell <mail@craig-mitchell.com> wrote:

Do you use it to compile to JavaScript or WebAssembly?

I'd love to compile Java to WebAssembly, but I'm too nervous about the edge cases.

On Friday, 4 September 2026 at 7:43:09 am UTC+10 Tim Macpherson wrote:

Maybe interesting for some:

.

I'm using TeaVM. Main problem is source map debugging will  usually descend into transpiled js, GWT doesn't have that problem otherwise ok it it lasts.

Yahoo Mail: Search, Organize, Conquer

--
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/9335d428-ddc6-4f79-b180-07f733051f05n%40googlegroups.com.

Re: GWt TeaVM comparison

Do you use it to compile to JavaScript or WebAssembly?

I'd love to compile Java to WebAssembly, but I'm too nervous about the edge cases.

On Friday, 4 September 2026 at 7:43:09 am UTC+10 Tim Macpherson wrote:

Maybe interesting for some:

.

I'm using TeaVM. Main problem is source map debugging will  usually descend into transpiled js, GWT doesn't have that problem otherwise ok it it lasts.

Yahoo Mail: Search, Organize, Conquer

--
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/9335d428-ddc6-4f79-b180-07f733051f05n%40googlegroups.com.

GWt TeaVM comparison

Maybe interesting for some:

.

I'm using TeaVM. Main problem is source map debugging will  usually descend into transpiled js, GWT doesn't have that problem otherwise ok it it lasts.

Yahoo Mail: Search, Organize, Conquer

--
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/1665484800.928484.1788471699651%40mail.yahoo.com.

Does GWT support CSP Trusted Types?

Hi everyone,

We're trying to implement Trusted Types (require-trusted-types-for 'script') in a GWT 2.13 application as part of CSP hardening.

We created a default Trusted Types policy, but when Trusted Types is enforced, the application fails during startup because the GWT-generated bootstrap code triggers TrustedScript/TrustedScriptURL violations.

Has anyone successfully implemented Trusted Types with GWT? Is there any official support or recommended approach for this?

Thanks in advance!

--
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/1b60c2ba-afa2-4f3d-ad8c-251c403729adn%40googlegroups.com.

Re: Apache commons-text security issues

Hi Mirza,

this is not a production jar as Colin pointed out. 

So if you are using the owasp plugin to find these, you can safely add this library to the owasp exclusions list - or setup you plugin/project so that you only scan libraries used in your deployable product. 

rg,

Leon.

On Tuesday, 14 July 2026 at 16:45:21 UTC+2 Mirza Hadžič wrote:

Hello,

note that commons-text 1.9 used in gwt-user is having security issues,
so please upgrade this library to newer version if possible. This jar is
used by net.sourceforge.htmlunit library.

Cheers,

Mirza

--
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/0df8389b-9106-4603-98c0-a650b2da9f3bn%40googlegroups.com.

Re: Apache commons-text security issues

Thanks for calling this out - however, the gwt-user dependency should never be on your runtime classpath, but only used when you compile/test/debug code for your project, so the scope her is limited.

Oddly, the non-maven build of GWT doesn't appear to include commons-text, I wonder if that is an oversight of the ant build, or if the dependency can simply be excluded.

I've filed https://github.com/gwtproject/gwt/issues/10370 to track this.

On Tuesday, July 14, 2026 at 9:45:21 AM UTC-5 had...@digitech.cz wrote:

Hello,

note that commons-text 1.9 used in gwt-user is having security issues,
so please upgrade this library to newer version if possible. This jar is
used by net.sourceforge.htmlunit library.

Cheers,

Mirza

--
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/bcfd0ff7-466c-41e0-a26e-c5b2aaa97710n%40googlegroups.com.

Apache commons-text security issues

Hello, note that commons-text 1.9 used in gwt-user is having security issues, so please upgrade this library to newer version if possible. This jar is used by net.sourceforge.htmlunit library. Cheers, Mirza -- 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/62b19755-f37d-4fd4-b583-39e5935b78dd%40digitech.cz.

Re: Elemental2 oddities

With the Elemental2 1.4.0-RC1 release, we now have a new WebGLContextAttributes class that now has a create method.

However, calling it:

WebGLContextAttributes contextAttributes = WebGLContextAttributes.create();

Results in:

com.google.gwt.core.client.JavaScriptException: (ReferenceError) : mOu_g$ is not defined

Which isn't what I expected.

Doing this still works:
WebGLContextAttributes contextAttributes = Js.uncheckedCast(JsPropertyMap.of());

I don't have the closure compiler knowledge to understand what's going on here.  Was the fix ( https://github.com/google/closure-compiler/issues/4250 ) not correct?

On Monday, 28 July 2025 at 8:20:37 pm UTC+10 Craig Mitchell wrote:

Thanks again Jens.  Issue raised:  https://github.com/google/closure-compiler/issues/4250

On Monday, 28 July 2025 at 6:55:23 pm UTC+10 Jens wrote:

Because it is only a dictionary (= a plain JS object)

https://registry.khronos.org/webgl/specs/latest/1.0/#5.2

In JS you simply do:

var canvas = document.getElementById('canvas');
var context = canvas.getContext('webgl', { antialias: false, stencil: true }); // 2nd argument is WebGLContextAttributes
var attributes = context.getContextAttributes();

Looks like it is again defined badly in closure-compiler externs. The generated elemental2 implementation should have a similar structure than for example elemental2 AddEventListenerOption. It is an interface with a static create() method which does exactly what you do in your solution.

See:

https://github.com/google/closure-compiler/blob/dc7f38bb0528b011984ef33a448c7941cf7e0b88/externs/browser/webgl.js#L2918

I think it should be @interface or @record instead of @constructor.

-- J.

Craig Mitchell schrieb am Montag, 28. Juli 2025 um 07:39:57 UTC+2:

I'm switching to use Elemental2, and it's fantastic.  All the bindings I'll ever need.  A big thank you to all that created it!

There are some strange things though.  Like when setting up a WebGLRenderingContext, we need to pass WebGLContextAttributes.

However, doing:

WebGLContextAttributes contextAttributes = new WebGLContextAttributes();

compiles fine, but at runtime throws:

TypeError: $wnd.WebGLContextAttributes is not a constructor

I figured out I can do this instead:

WebGLContextAttributes contextAttributes = Js.uncheckedCast(JsPropertyMap.of());

But why can't I just use its constructor?  Am I doing something wrong?

--
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/126d9f3a-513b-4aeb-bd33-1adccce25605n%40googlegroups.com.

Re: Elemental2 WebRTC createOffer and createAnswer are incorrect

It took a year, but the newly released Elemental2 1.4.0-RC1 now has this fix.  🎉

On Wednesday, 20 August 2025 at 9:40:32 am UTC+10 Craig Mitchell wrote:

Following up on my own comment:  A request for a new build with updated closure externs has been made:  https://github.com/google/elemental2/issues/175

On Sunday, 20 July 2025 at 9:37:31 am UTC+10 Craig Mitchell wrote:

Now the good people at the closure-compiler have fixed the error ( https://github.com/google/closure-compiler/commit/5aadfa78592a2778ae4cac52613fb9238228b3e8 ), I see I can build a new version of Elemental2 locally ( https://github.com/google/elemental2?tab=readme-ov-file#build-gwt-compatible-maven-jar-files ).

It would be nice to get an offical Elemental2 build, and have it pushed to Maven.  It looks like one hasn't been done for 9 months, is there any offical Elemental2 release schedule?

On Tuesday, 15 July 2025 at 7:37:27 pm UTC+10 Craig Mitchell wrote:

Thanks Jens.  Bug raised:  https://github.com/google/closure-compiler/issues/4249

On Tuesday, 15 July 2025 at 6:49:06 pm UTC+10 Jens wrote:

And this works great.  But it would be nice to fix Elemental2.

You have to file an issue against closure-compiler because elemental2 takes their definition: https://github.com/google/closure-compiler/blob/15c5dd492cbb9dcdfd24d01f75b64e3e9b2291eb/externs/browser/w3c_rtc.js#L3586C23-L3586C44

-- 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/4cb68587-ffe6-40e2-8153-6e0d56bb291bn%40googlegroups.com.

Learn more about our updated Terms of Service

vaughnjjoan@gmail.com  Every couple of years, we update our Terms of Service. We wanted to let you know ahead of time that the next update will be on July 30, 2026. These changes won’t affect the way you use our services, but they should help make it easier for you to understand what to expect from Google — and what we expect from you — as you use our services. You can review the new terms here. If you’re based in the European Economic Area (EEA) or Switzerland, we’ve also provided a summary of the key changes to the EEA version of our terms. At a glance, here’s what this update means for you: In general: We added a section to help you better understand why our services may access the internet when not actively engaged, to encourage you to check your Internet service plan and your device and network settings, as each of those may affect your costs. We updated and clarified our Settling disputes, governing law, and courts section. We make it clearer how various sections in our terms relate to each other. If you’re based in the EEA: In addition to the changes in the In general section, we updated various sections to reflect the latest EEA laws and regulations that apply to our services, including: Google’s obligation to make legally-required updates to our digital content, services, and goods. A new, online “withdrawal button” in the EEA instructions on withdrawal section. We also removed the Handling requests for your data section, because we’re centralizing our data disclosure language on our main data disclosure policy page. If you’re based outside the EEA:  In addition to the changes in the In general section, we added new disclosures and disclaimers, including ones about AI outputs. If you’re based in India, we also added new reporting language about our obligations if you violate applicable law. If you’re a parent or guardian, and you allow your child to use the services, please review the updates to our terms with your child and help them decide whether they need to make any changes to their account. Please remember that these terms apply to you and you’re responsible for your child’s activity on the services. If you don’t agree to the new terms, you should remove your content and stop using the services. You can also end your relationship with us at any time, without penalty, by closing your Google Account. Thank you for using Google services!  © 2026 Google Ireland Ltd, Gordon House, Barrow Street, Dublin 4, Ireland.  You have received this email to update you about important changes to Google’s Terms of Service.

Re: GWT 2.13.1 released

Looks good here too (rebuild with GWT 2.13.1 SDK in Eclipse 2026-06 with the GWT Eclipse Plugin).

On Friday, June 19, 2026 at 8:50:36 PM UTC-7 Craig Mitchell wrote:

Working great here too.  Thank you!

On Saturday, 20 June 2026 at 7:38:37 am UTC+10 Juan Pablo Gardella wrote:

Great! My apps worked well with that version, thanks!

On Fri, Jun 19, 2026 at 4:22 PM Colin Alworth <co...@colinalworth.com> wrote:

This is a small bugfix release, with four changes:

• Permit failure to delete files on Windows, and close finished logs. This is a regression, caused by trying to use Guava to replace some bespoke utility classes.
• Simplify RTA iframe loading in Firefox. This addresses a change in behavior in Firefox, although in most cases applications compiled with older versions of GWT should have a workaround automatically applied by Firefox.
• Use Objects.equals to compare record fields for null support. As the current implementation of records was producing an incorrect equals method and this was a low risk fix, this was backported.
• Include GWT version, commit in JFR output. This ensures that we have a baseline for compiled size improvements going forward.

--
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/9659b3ed-e134-4ea3-88c5-995ecd3919f5n%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/88b5f5ff-e209-4ac5-98ae-8c3593ee9558n%40googlegroups.com.

Re: GWT 2.13.1 released

Working great here too.  Thank you!

On Saturday, 20 June 2026 at 7:38:37 am UTC+10 Juan Pablo Gardella wrote:

Great! My apps worked well with that version, thanks!

On Fri, Jun 19, 2026 at 4:22 PM Colin Alworth <co...@colinalworth.com> wrote:

This is a small bugfix release, with four changes:

• Permit failure to delete files on Windows, and close finished logs. This is a regression, caused by trying to use Guava to replace some bespoke utility classes.
• Simplify RTA iframe loading in Firefox. This addresses a change in behavior in Firefox, although in most cases applications compiled with older versions of GWT should have a workaround automatically applied by Firefox.
• Use Objects.equals to compare record fields for null support. As the current implementation of records was producing an incorrect equals method and this was a low risk fix, this was backported.
• Include GWT version, commit in JFR output. This ensures that we have a baseline for compiled size improvements going forward.

--
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/9659b3ed-e134-4ea3-88c5-995ecd3919f5n%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/81042bec-ad81-46f8-ac67-ef228bca6d5bn%40googlegroups.com.

Re: GWT 2.13.1 released

Great! My apps worked well with that version, thanks!

On Fri, Jun 19, 2026 at 4:22 PM Colin Alworth <colin@colinalworth.com> wrote:

This is a small bugfix release, with four changes:

• Permit failure to delete files on Windows, and close finished logs. This is a regression, caused by trying to use Guava to replace some bespoke utility classes.
• Simplify RTA iframe loading in Firefox. This addresses a change in behavior in Firefox, although in most cases applications compiled with older versions of GWT should have a workaround automatically applied by Firefox.
• Use Objects.equals to compare record fields for null support. As the current implementation of records was producing an incorrect equals method and this was a low risk fix, this was backported.
• Include GWT version, commit in JFR output. This ensures that we have a baseline for compiled size improvements going forward.

--
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/9659b3ed-e134-4ea3-88c5-995ecd3919f5n%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%2BkiFseg6CXhCOZ_5X8s57J-oQRZo-kRxGQwCWcPEfHm3KxQOA%40mail.gmail.com.

GWT 2.13.1 released

This is a small bugfix release, with four changes:

Permit failure to delete files on Windows, and close finished logs. This is a regression, caused by trying to use Guava to replace some bespoke utility classes.

Simplify RTA iframe loading in Firefox. This addresses a change in behavior in Firefox, although in most cases applications compiled with older versions of GWT should have a workaround automatically applied by Firefox.

Use Objects.equals to compare record fields for null support. As the current implementation of records was producing an incorrect equals method and this was a low risk fix, this was backported.

Include GWT version, commit in JFR output. This ensures that we have a baseline for compiled size improvements going forward.

--
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/9659b3ed-e134-4ea3-88c5-995ecd3919f5n%40googlegroups.com.

Re: GWT Deferred Binding Error – UiBinder Not Resolved from Dependent Module (phoenix-air)

Oh, wait. I see  com.shipco.phoenix.air.Air in there, so it probably isn't the one from  com.shipco.phoenix.air.

Sorry, unless you can create a simpler example, this is too complicated to work out without seeing all the code.

On Saturday, 9 May 2026 at 9:07:11 am UTC+10 Craig Mitchell wrote:

I don't know which gwt.xml file this is, but if it's the one from com.shipco.phoenix.air, then it's missing <inherits name="com.shipco.phoenix.client" />   (unless it's included below the screenshot).

On Friday, 8 May 2026 at 7:24:19 pm UTC+10 Arpan Ameta wrote:

Please find SS of air.gwt.xml, main(application.gwt.xml), air(pom.xml), main(pom.xml) and how air dependency is added to it.

On Friday, May 8, 2026 at 1:44:26 PM UTC+5:30 Craig Mitchell wrote:

I would have thought the error would be in your module.gwt.xml.  The com.shipco.phoenix.air isn't correctly inheriting in the com.shipco.phoenix.client.  That's what the error is indicating anyway.  However, without looking at all your code, this is just a guess.

On Friday, 8 May 2026 at 4:39:26 pm UTC+10 Arpan Ameta wrote:

Hello, 
Please the SS of the required classes.


can you please suggest what should i fix in this class because it is being used by other module as well so can't make any change blindly.

br,

Arpan Ameta

On Friday, May 1, 2026 at 7:26:32 AM UTC+5:30 Craig Mitchell wrote:

Did you fix the error with your MonitorServiceInterfaceProxyGenerator?

On Thursday, 30 April 2026 at 7:01:30 pm UTC+10 Arpan Ameta wrote:

Hello All,

Anyone can please help us...??

On Wednesday, March 25, 2026 at 12:13:19 PM UTC+5:30 Arpan Ameta wrote:

Hi Craig,

Thanks for pointing that out.

Yes, in the screenshot I shared, there is indeed an error related to MonitorServiceInterfaceProxyGenerator. However, this is a custom generator used across multiple modules in our project, and those modules are compiling and working fine even after the upgrade.

That’s why I’m a bit unsure if this generator is the root cause here, or if it’s just a side effect of something failing earlier in the compilation chain.

Also, the failure still surfaces specifically at:

AwbCustomer.AwbCustomerUiBinder

which makes it look like a UiBinder deferred binding issue at first glance.

That said, I agree with your point — if the generator fails, it could potentially break the binding process. I’ll try isolating this further by:

• Checking if this module has any differences in how the generator is used
• Verifying if any recent changes or stricter rules in GWT 2.12.0 / JDK 17 are affecting it
• Temporarily disabling or bypassing the generator (if possible) to see if the error persists

I’ll update once I have more findings.

Thanks again for your help!

On Wednesday, March 25, 2026 at 4:33:36 AM UTC+5:30 Craig Mitchell wrote:

Is your screenshot saying there is an error with the MonitorServiceInterfaceProxyGenerator?  I've no clue what that is, but that error could be causing the error with the AwbCustomer.

On Tuesday, 24 March 2026 at 10:56:33 pm UTC+11 Arpan Ameta wrote:

Hi Craig,

Thanks for your response.

Yes, the error occurs during compilation (GWT Code Server / compile), but interestingly I do not see the “Unable to find resource” error for the AwbCustomer.ui.xml file.

The .ui.xml file is present in the correct package and follows the same naming convention as other working modules. That’s why this is a bit confusing — if it were a missing or misplaced file, I would expect that specific error to show up.

In this case, the compilation fails directly with the deferred binding error:

Failed to resolve 'AwbCustomer.AwbCustomerUiBinder' via deferred binding

Also worth noting:

• Other UiBinder classes in different modules are compiling fine

• This issue started only after upgrading to GWT 2.12.0 and JDK 17

• The structure and setup of this module is consistent with others that are working

Because of this, I’m wondering if this could be related to stricter checks in the newer GWT version or something subtle being missed in this particular class/module.

Please let me know if there’s anything specific you’d recommend checking beyond the usual .ui.xml placement — happy to dig deeper.

Thanks again for your help!

On Tuesday, March 24, 2026 at 2:53:06 PM UTC+5:30 Craig Mitchell wrote:

I assume you get this error when running, and the GWT Code Server fails to compile that class.

If you've misspelt or misplaced the ui.xml file, you should also get an error like:

[ERROR] Unable to find resource: blah/blah/.../AwbCustomer.ui.xml

Do you see that error?

On Tuesday, 24 March 2026 at 5:58:33 pm UTC+11 Arpan Ameta wrote:

Hi Team,

I’m currently facing an issue after upgrading our project to GWT 2.12.0 and JDK 17, and I’d really appreciate any guidance or suggestions from the community.

While most of our modules are compiling and working fine post-upgrade, one specific module is failing during GWT compilation with the following error:

[ERROR] Failed to resolve 'com.shipco.air.modules.awb.client.airimport.view.awbpopup.AwbCustomer.AwbCustomerUiBinder' via deferred binding

From the logs, it appears to be a UiBinder-related issue during deferred binding. The same pattern and structure are used in other modules, and they are working without any problems.

A few points to highlight:

• This issue started only after upgrading to GWT 2.12.0 and JDK 17
• Other UiBinder-based components in different modules are compiling successfully
• The .ui.xml file exists and is correctly placed
• Module inheritance and source paths appear to be properly configured
• There is also a custom generator involved (MonitorServiceInterfaceProxyGenerator), though it's used elsewhere without issues

At this point, I’m unsure whether this is:

• A compatibility issue with GWT 2.12.0 or JDK 17
• A stricter validation introduced in newer versions
• Or something specific being missed in this module

If anyone has encountered a similar issue or has suggestions on what to check next, your help would be greatly appreciated.

Thanks in advance for your support!

On Friday, March 20, 2026 at 6:18:18 PM UTC+5:30 Thomas Broyer wrote:

On Friday, March 20, 2026 at 1:19:56 PM UTC+1 arpanam...@gmail.com wrote:

> 
>   * Maven build with net.ltgt.gwt.maven:gwt-maven-plugin
> ----

> 
> Any insights or best practices for structuring GWT modules across Maven projects would be really helpful.

See https://tbroyer.github.io/gwt-maven-plugin/ and https://tbroyer.github.io/gwt-maven-plugin/usage.html

For a client-only library, use `<packaging>gwt-lib</packaging>`, and then depend on it using <type>gwt-lib</type> for better running/debugging support: https://tbroyer.github.io/gwt-maven-plugin/codeserver.html

--
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/474d5c73-5659-4b4b-9c04-b07a43a49af1n%40googlegroups.com.