GWT 2.13 released

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.

Re: GWT 2.8.0 OOM Error on compilation

I've sent you an email off-list to discuss times for a call.

There are a number of other questions in my last message that would be helpful to answer, though I can at least say this much:

 * With only one <hash>.cache.js, there is only one module (i.e. .gwt.xml file) being compiled, the other files must be to partition the project in some way. There is also then only one permutation, all the others must either be collapsed through settings in those .gwt.xml files, or through the -setProperty  passed to the compiler.

 * 1.5k split points is _a lot_. Almost certainly you are spending far more memory and time to compile them than you are getting benefit out of them - even without the SOYC report, you should be able to quickly decide how many of them are worth keeping by their size, and then track down where they come from and remove most of them. There are automated options to give the compiler discretion on which split points to remove as well, but a better option is to outright remove the useless ones and save your users extra load time for tiny files, and save yourself compile time. A quick grouping of these files by size would help to understand which ones bring benefit and which don't.

 * In draft mode, split points _should_ be disabled, so this also brings to mind the question of "how are you compiling for prod mode" - how much memory and time does it take to produce those 1.5k split points? From there, hopefully we can disable split points and work towards a usable command for quick local builds.

On Wednesday, February 11, 2026 at 12:29:46 AM UTC-6 AFK wrote:

There is only 1  <hashname>.cache.js, and almost 1.5k *.cache.js.

there's only 1 entry point module, and everything else are just sub-modules inherited. 

It would be great if we can have a quick call whenever you can. Just let me know the best time.

Thank you!

On Wednesday, 11 February 2026 at 04:25:21 UTC+2 Colin Alworth wrote:

That seems to be a big project, but it is hard to be sure - "module", is that just a single module, and "almost 1.5k .cache.js files" is that the result of a draft compile, or a prod compile? If it is a prod compile, what settings allow that to succeed? 

How big are those files, and how are they grouped? Odds are, if this is a prod build, there are only a few (5? 10? 50?) that have a long <hashname>.cache.js, and the rest are likely to be short integer names within a deferredjs/<hashname>/ directory, indicating they are "split points", JS that isn't downloaded until it is needed. With, say, 50 permutations (browsers X locales etc), and only one single module passed to the compiler, that suggests something like 30 split points. If most of the integer named ones are small, there is likely a lot of cleanup you can do to improve compile time and load times for users.

That stack size seems ridiculously big - 1g stack is the max that the JVM supports I believe, and the default is usually less than 1mb. I don't think it should make a huge impact here, but it is surprising to see it that large, especially when the default usually works.

Beyond that, without more specifics it will be hard to make suggestions for code that used to work and now doesn't (except asking obvious questions like "what has changed since it last worked", which you might be unable to answer). I would be open to a short screensharing call to help understand more quickly how this is structured and what is happening.

On Tuesday, February 10, 2026 at 12:59:53 AM UTC-6 AFK wrote:

java ^
-Xms10g ^
-Xmx36g ^
-Xss1024m ^
-Dgwt.jjs.maxThreads=1 ^
-XX:+UseG1GC ^
-cp "...\src;...\classes;...\gwt-user.jar;...\gwt-dev.jar;...\gwt-lib\*" ^
com.google.gwt.dev.Compiler ^
-localWorkers 1 ^
-style OBF ^
-optimize 0 ^
-draftCompile ^
-XdisableCastChecking ^
-XdisableClassMetadata ^
-setProperty locale=en ^
-war "...\GWT_TEST_OUTPUT" ^
-extra "...\GWT_EXTRA" ^
-deploy "...\GWT_DEPLOY" ^
-logLevel ERROR ^
"module" > "...\gwt-compile.log" 2>&1

here is the command i use. (using cmd on windows) 

i can see in the project almost 1.5k *.cache.js files.

also, there 34 *.gwt.xml files.

the project is using mxgraph/mxClient library

On Monday, 9 February 2026 at 20:50:57 UTC+2 Colin Alworth wrote:

Without seeing the project, it'd be hard to guess, so a few quick notes:

 * ControlFlowAnalyzer is run as part of generating SOYC output, which is going to cost something and be entirely unnecessary for a dev build - arguably even inaccurate to the point of being counterproductive to even look at it (as it would be showing you why your app is so big... when you deliberately are building with draftCompile). Turn off SOYC/compileReport/etc, it doesn't make sense for this build.

 * GWT 2.8.0 is pretty old - you might not be able to update all the way to latest, but maybe a short step or two to see if it resolves something? (2.8.2, 2.9.0, etc)

 * What other details can you share - what args besides -draftCompile are you passing, and roughly how big is your application (in terms of Java LoC or JS output)? Also, can you confirm how you're running the compile, and how you are passing -Xmx36g (in case you're accidentally passing it to the build tool and not to GWT itself)?

On Monday, February 9, 2026 at 12:32:57 PM UTC-6 AFK wrote:

Hey guys, Whenever i compile my GWT project, i get an OOM error:

Compiling module x Compiling 1 permutation [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads java.lang.OutOfMemoryError: Java heap space at com.google.gwt.thirdparty.guava.common.collect.Iterables.concat(Iterables.java:495) at com.google.gwt.thirdparty.guava.common.collect.Iterables.concat(Iterables.java:434) at com.google.gwt.dev.jjs.ast.JMethod.getOverriddenMethodsIncludingSelf(JMethod.java:579) at com.google.gwt.dev.jjs.ast.JMethod.canBeReferencedExternally(JMethod.java:85) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:626) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:371) at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:265) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:118) at com.google.gwt.dev.jjs.ast.JExpressionStatement.traverse(JExpressionStatement.java:42) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146) at com.google.gwt.dev.jjs.ast.JVisitor.acceptWithInsertRemove(JVisitor.java:168) at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:92) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:139) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:135) at com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:83) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:786) at com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:778) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:618) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:371) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:478) at com.google.gwt.dev.jjs.ast.js.JsniMethodRef.traverse(JsniMethodRef.java:69) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146) at com.google.gwt.dev.jjs.ast.JVisitor.acceptImmutable(JVisitor.java:154) at com.google.gwt.dev.jjs.ast.js.JsniMethodBody.traverse(JsniMethodBody.java:136) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) [ERROR] Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...) [ERROR] Unrecoverable exception, shutting down com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:56) at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:74) at java.lang.Thread.run(Thread.java:750) [ERROR] Not all permutation were compiled , completed (0/1)

my project is kinda old, using jars, and compiling in cmd.

I'm giving the compiler 36GB ram, compiling for only firefox, using draftCompile and much more, but nothing is working.

I'm also fairly new to GWT, and i'm really wondering how did the dev working on this specific project before me could compile 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/4013fbce-c46d-4a3b-a45a-b7a103aa717dn%40googlegroups.com.

Re: GWT 2.8.0 OOM Error on compilation

There is only 1  <hashname>.cache.js, and almost 1.5k *.cache.js.

there's only 1 entry point module, and everything else are just sub-modules inherited. 

It would be great if we can have a quick call whenever you can. Just let me know the best time.

Thank you!

On Wednesday, 11 February 2026 at 04:25:21 UTC+2 Colin Alworth wrote:

That seems to be a big project, but it is hard to be sure - "module", is that just a single module, and "almost 1.5k .cache.js files" is that the result of a draft compile, or a prod compile? If it is a prod compile, what settings allow that to succeed? 

How big are those files, and how are they grouped? Odds are, if this is a prod build, there are only a few (5? 10? 50?) that have a long <hashname>.cache.js, and the rest are likely to be short integer names within a deferredjs/<hashname>/ directory, indicating they are "split points", JS that isn't downloaded until it is needed. With, say, 50 permutations (browsers X locales etc), and only one single module passed to the compiler, that suggests something like 30 split points. If most of the integer named ones are small, there is likely a lot of cleanup you can do to improve compile time and load times for users.

That stack size seems ridiculously big - 1g stack is the max that the JVM supports I believe, and the default is usually less than 1mb. I don't think it should make a huge impact here, but it is surprising to see it that large, especially when the default usually works.

Beyond that, without more specifics it will be hard to make suggestions for code that used to work and now doesn't (except asking obvious questions like "what has changed since it last worked", which you might be unable to answer). I would be open to a short screensharing call to help understand more quickly how this is structured and what is happening.

On Tuesday, February 10, 2026 at 12:59:53 AM UTC-6 AFK wrote:

java ^
-Xms10g ^
-Xmx36g ^
-Xss1024m ^
-Dgwt.jjs.maxThreads=1 ^
-XX:+UseG1GC ^
-cp "...\src;...\classes;...\gwt-user.jar;...\gwt-dev.jar;...\gwt-lib\*" ^
com.google.gwt.dev.Compiler ^
-localWorkers 1 ^
-style OBF ^
-optimize 0 ^
-draftCompile ^
-XdisableCastChecking ^
-XdisableClassMetadata ^
-setProperty locale=en ^
-war "...\GWT_TEST_OUTPUT" ^
-extra "...\GWT_EXTRA" ^
-deploy "...\GWT_DEPLOY" ^
-logLevel ERROR ^
"module" > "...\gwt-compile.log" 2>&1

here is the command i use. (using cmd on windows) 

i can see in the project almost 1.5k *.cache.js files.

also, there 34 *.gwt.xml files.

the project is using mxgraph/mxClient library

On Monday, 9 February 2026 at 20:50:57 UTC+2 Colin Alworth wrote:

Without seeing the project, it'd be hard to guess, so a few quick notes:

 * ControlFlowAnalyzer is run as part of generating SOYC output, which is going to cost something and be entirely unnecessary for a dev build - arguably even inaccurate to the point of being counterproductive to even look at it (as it would be showing you why your app is so big... when you deliberately are building with draftCompile). Turn off SOYC/compileReport/etc, it doesn't make sense for this build.

 * GWT 2.8.0 is pretty old - you might not be able to update all the way to latest, but maybe a short step or two to see if it resolves something? (2.8.2, 2.9.0, etc)

 * What other details can you share - what args besides -draftCompile are you passing, and roughly how big is your application (in terms of Java LoC or JS output)? Also, can you confirm how you're running the compile, and how you are passing -Xmx36g (in case you're accidentally passing it to the build tool and not to GWT itself)?

On Monday, February 9, 2026 at 12:32:57 PM UTC-6 AFK wrote:

Hey guys, Whenever i compile my GWT project, i get an OOM error:

Compiling module x Compiling 1 permutation [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads java.lang.OutOfMemoryError: Java heap space at com.google.gwt.thirdparty.guava.common.collect.Iterables.concat(Iterables.java:495) at com.google.gwt.thirdparty.guava.common.collect.Iterables.concat(Iterables.java:434) at com.google.gwt.dev.jjs.ast.JMethod.getOverriddenMethodsIncludingSelf(JMethod.java:579) at com.google.gwt.dev.jjs.ast.JMethod.canBeReferencedExternally(JMethod.java:85) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:626) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:371) at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:265) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:118) at com.google.gwt.dev.jjs.ast.JExpressionStatement.traverse(JExpressionStatement.java:42) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146) at com.google.gwt.dev.jjs.ast.JVisitor.acceptWithInsertRemove(JVisitor.java:168) at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:92) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:139) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:135) at com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:83) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:786) at com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:778) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:618) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:371) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:478) at com.google.gwt.dev.jjs.ast.js.JsniMethodRef.traverse(JsniMethodRef.java:69) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146) at com.google.gwt.dev.jjs.ast.JVisitor.acceptImmutable(JVisitor.java:154) at com.google.gwt.dev.jjs.ast.js.JsniMethodBody.traverse(JsniMethodBody.java:136) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) [ERROR] Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...) [ERROR] Unrecoverable exception, shutting down com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:56) at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:74) at java.lang.Thread.run(Thread.java:750) [ERROR] Not all permutation were compiled , completed (0/1)

my project is kinda old, using jars, and compiling in cmd.

I'm giving the compiler 36GB ram, compiling for only firefox, using draftCompile and much more, but nothing is working.

I'm also fairly new to GWT, and i'm really wondering how did the dev working on this specific project before me could compile 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/d09c822a-ff0e-44ce-8bf8-1e1270ac62dan%40googlegroups.com.

Re: GWT 2.8.0 OOM Error on compilation

That seems to be a big project, but it is hard to be sure - "module", is that just a single module, and "almost 1.5k .cache.js files" is that the result of a draft compile, or a prod compile? If it is a prod compile, what settings allow that to succeed? 

How big are those files, and how are they grouped? Odds are, if this is a prod build, there are only a few (5? 10? 50?) that have a long <hashname>.cache.js, and the rest are likely to be short integer names within a deferredjs/<hashname>/ directory, indicating they are "split points", JS that isn't downloaded until it is needed. With, say, 50 permutations (browsers X locales etc), and only one single module passed to the compiler, that suggests something like 30 split points. If most of the integer named ones are small, there is likely a lot of cleanup you can do to improve compile time and load times for users.

That stack size seems ridiculously big - 1g stack is the max that the JVM supports I believe, and the default is usually less than 1mb. I don't think it should make a huge impact here, but it is surprising to see it that large, especially when the default usually works.

Beyond that, without more specifics it will be hard to make suggestions for code that used to work and now doesn't (except asking obvious questions like "what has changed since it last worked", which you might be unable to answer). I would be open to a short screensharing call to help understand more quickly how this is structured and what is happening.

On Tuesday, February 10, 2026 at 12:59:53 AM UTC-6 AFK wrote:

java ^
-Xms10g ^
-Xmx36g ^
-Xss1024m ^
-Dgwt.jjs.maxThreads=1 ^
-XX:+UseG1GC ^
-cp "...\src;...\classes;...\gwt-user.jar;...\gwt-dev.jar;...\gwt-lib\*" ^
com.google.gwt.dev.Compiler ^
-localWorkers 1 ^
-style OBF ^
-optimize 0 ^
-draftCompile ^
-XdisableCastChecking ^
-XdisableClassMetadata ^
-setProperty locale=en ^
-war "...\GWT_TEST_OUTPUT" ^
-extra "...\GWT_EXTRA" ^
-deploy "...\GWT_DEPLOY" ^
-logLevel ERROR ^
"module" > "...\gwt-compile.log" 2>&1

here is the command i use. (using cmd on windows) 

i can see in the project almost 1.5k *.cache.js files.

also, there 34 *.gwt.xml files.

the project is using mxgraph/mxClient library

On Monday, 9 February 2026 at 20:50:57 UTC+2 Colin Alworth wrote:

Without seeing the project, it'd be hard to guess, so a few quick notes:

 * ControlFlowAnalyzer is run as part of generating SOYC output, which is going to cost something and be entirely unnecessary for a dev build - arguably even inaccurate to the point of being counterproductive to even look at it (as it would be showing you why your app is so big... when you deliberately are building with draftCompile). Turn off SOYC/compileReport/etc, it doesn't make sense for this build.

 * GWT 2.8.0 is pretty old - you might not be able to update all the way to latest, but maybe a short step or two to see if it resolves something? (2.8.2, 2.9.0, etc)

 * What other details can you share - what args besides -draftCompile are you passing, and roughly how big is your application (in terms of Java LoC or JS output)? Also, can you confirm how you're running the compile, and how you are passing -Xmx36g (in case you're accidentally passing it to the build tool and not to GWT itself)?

On Monday, February 9, 2026 at 12:32:57 PM UTC-6 AFK wrote:

Hey guys, Whenever i compile my GWT project, i get an OOM error:

Compiling module x Compiling 1 permutation [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads java.lang.OutOfMemoryError: Java heap space at com.google.gwt.thirdparty.guava.common.collect.Iterables.concat(Iterables.java:495) at com.google.gwt.thirdparty.guava.common.collect.Iterables.concat(Iterables.java:434) at com.google.gwt.dev.jjs.ast.JMethod.getOverriddenMethodsIncludingSelf(JMethod.java:579) at com.google.gwt.dev.jjs.ast.JMethod.canBeReferencedExternally(JMethod.java:85) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:626) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:371) at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:265) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:118) at com.google.gwt.dev.jjs.ast.JExpressionStatement.traverse(JExpressionStatement.java:42) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146) at com.google.gwt.dev.jjs.ast.JVisitor.acceptWithInsertRemove(JVisitor.java:168) at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:92) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:139) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:135) at com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:83) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:786) at com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:778) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:618) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:371) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:478) at com.google.gwt.dev.jjs.ast.js.JsniMethodRef.traverse(JsniMethodRef.java:69) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146) at com.google.gwt.dev.jjs.ast.JVisitor.acceptImmutable(JVisitor.java:154) at com.google.gwt.dev.jjs.ast.js.JsniMethodBody.traverse(JsniMethodBody.java:136) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) [ERROR] Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...) [ERROR] Unrecoverable exception, shutting down com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:56) at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:74) at java.lang.Thread.run(Thread.java:750) [ERROR] Not all permutation were compiled , completed (0/1)

my project is kinda old, using jars, and compiling in cmd.

I'm giving the compiler 36GB ram, compiling for only firefox, using draftCompile and much more, but nothing is working.

I'm also fairly new to GWT, and i'm really wondering how did the dev working on this specific project before me could compile 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/ee6ed9e1-0011-4c75-a8b3-f70f409ac195n%40googlegroups.com.

Re: Nalu 4.0.0 released

Usually there are no problems using Nalu with different widget libs. GWT, GXT, Elemento, Element and Domino-UI are working well with Nalu. There is one thing you need to check: Is you ui-lib widget based or element based. Then choose the right module and everything is fine. In case that there are 'very special' SmartGWT implementations, we can think about creating an own SmartGWT-Model.  

I am not familiar with SmartGWT. But as long as all SmartGWT-code stays inside the component, everything is fine. 

if you have more questions, feel free to contact me: https://app.element.io/#/room/#Nalukit42_Lobby:gitter.im

pavel....@gmail.com schrieb am Sonntag, 8. Februar 2026 um 22:49:18 UTC+1:

Hi,

It would be interesting to hear your opinion on how difficult it would be to provide SmartGWT support.

четвер, 15 січня 2026 р. о 07:25:06 UTC+1 Frank Hossfeld пише:

We added some new features:

* clean URL support
* url parameter support

For more informations please visit: https://github.com/NaluKit/nalu/releases/tag/4.0.0

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/b1bd438f-2d85-43a7-95a4-56c6ae93c51bn%40googlegroups.com.

Re: GWT 2.8.0 OOM Error on compilation

java ^
-Xms10g ^
-Xmx36g ^
-Xss1024m ^
-Dgwt.jjs.maxThreads=1 ^
-XX:+UseG1GC ^
-cp "...\src;...\classes;...\gwt-user.jar;...\gwt-dev.jar;...\gwt-lib\*" ^
com.google.gwt.dev.Compiler ^
-localWorkers 1 ^
-style OBF ^
-optimize 0 ^
-draftCompile ^
-XdisableCastChecking ^
-XdisableClassMetadata ^
-setProperty locale=en ^
-war "...\GWT_TEST_OUTPUT" ^
-extra "...\GWT_EXTRA" ^
-deploy "...\GWT_DEPLOY" ^
-logLevel ERROR ^
"module" > "...\gwt-compile.log" 2>&1

here is the command i use. (using cmd on windows) 

i can see in the project almost 1.5k *.cache.js files.

also, there 34 *.gwt.xml files.

the project is using mxgraph/mxClient library

On Monday, 9 February 2026 at 20:50:57 UTC+2 Colin Alworth wrote:

Without seeing the project, it'd be hard to guess, so a few quick notes:

 * ControlFlowAnalyzer is run as part of generating SOYC output, which is going to cost something and be entirely unnecessary for a dev build - arguably even inaccurate to the point of being counterproductive to even look at it (as it would be showing you why your app is so big... when you deliberately are building with draftCompile). Turn off SOYC/compileReport/etc, it doesn't make sense for this build.

 * GWT 2.8.0 is pretty old - you might not be able to update all the way to latest, but maybe a short step or two to see if it resolves something? (2.8.2, 2.9.0, etc)

 * What other details can you share - what args besides -draftCompile are you passing, and roughly how big is your application (in terms of Java LoC or JS output)? Also, can you confirm how you're running the compile, and how you are passing -Xmx36g (in case you're accidentally passing it to the build tool and not to GWT itself)?

On Monday, February 9, 2026 at 12:32:57 PM UTC-6 AFK wrote:

Hey guys, Whenever i compile my GWT project, i get an OOM error:

Compiling module x Compiling 1 permutation [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads java.lang.OutOfMemoryError: Java heap space at com.google.gwt.thirdparty.guava.common.collect.Iterables.concat(Iterables.java:495) at com.google.gwt.thirdparty.guava.common.collect.Iterables.concat(Iterables.java:434) at com.google.gwt.dev.jjs.ast.JMethod.getOverriddenMethodsIncludingSelf(JMethod.java:579) at com.google.gwt.dev.jjs.ast.JMethod.canBeReferencedExternally(JMethod.java:85) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:626) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:371) at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:265) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:118) at com.google.gwt.dev.jjs.ast.JExpressionStatement.traverse(JExpressionStatement.java:42) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146) at com.google.gwt.dev.jjs.ast.JVisitor.acceptWithInsertRemove(JVisitor.java:168) at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:92) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:139) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:135) at com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:83) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:786) at com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:778) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:618) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:371) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:478) at com.google.gwt.dev.jjs.ast.js.JsniMethodRef.traverse(JsniMethodRef.java:69) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146) at com.google.gwt.dev.jjs.ast.JVisitor.acceptImmutable(JVisitor.java:154) at com.google.gwt.dev.jjs.ast.js.JsniMethodBody.traverse(JsniMethodBody.java:136) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) [ERROR] Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...) [ERROR] Unrecoverable exception, shutting down com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:56) at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:74) at java.lang.Thread.run(Thread.java:750) [ERROR] Not all permutation were compiled , completed (0/1)

my project is kinda old, using jars, and compiling in cmd.

I'm giving the compiler 36GB ram, compiling for only firefox, using draftCompile and much more, but nothing is working.

I'm also fairly new to GWT, and i'm really wondering how did the dev working on this specific project before me could compile 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/2824bb72-3790-41d0-9dc5-409a9e089738n%40googlegroups.com.

Re: GWT 2.8.0 OOM Error on compilation

Without seeing the project, it'd be hard to guess, so a few quick notes:

 * ControlFlowAnalyzer is run as part of generating SOYC output, which is going to cost something and be entirely unnecessary for a dev build - arguably even inaccurate to the point of being counterproductive to even look at it (as it would be showing you why your app is so big... when you deliberately are building with draftCompile). Turn off SOYC/compileReport/etc, it doesn't make sense for this build.

 * GWT 2.8.0 is pretty old - you might not be able to update all the way to latest, but maybe a short step or two to see if it resolves something? (2.8.2, 2.9.0, etc)

 * What other details can you share - what args besides -draftCompile are you passing, and roughly how big is your application (in terms of Java LoC or JS output)? Also, can you confirm how you're running the compile, and how you are passing -Xmx36g (in case you're accidentally passing it to the build tool and not to GWT itself)?

On Monday, February 9, 2026 at 12:32:57 PM UTC-6 AFK wrote:

Hey guys, Whenever i compile my GWT project, i get an OOM error:

Compiling module x Compiling 1 permutation [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads java.lang.OutOfMemoryError: Java heap space at com.google.gwt.thirdparty.guava.common.collect.Iterables.concat(Iterables.java:495) at com.google.gwt.thirdparty.guava.common.collect.Iterables.concat(Iterables.java:434) at com.google.gwt.dev.jjs.ast.JMethod.getOverriddenMethodsIncludingSelf(JMethod.java:579) at com.google.gwt.dev.jjs.ast.JMethod.canBeReferencedExternally(JMethod.java:85) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:626) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:371) at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:265) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:118) at com.google.gwt.dev.jjs.ast.JExpressionStatement.traverse(JExpressionStatement.java:42) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146) at com.google.gwt.dev.jjs.ast.JVisitor.acceptWithInsertRemove(JVisitor.java:168) at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:92) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:139) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:135) at com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:83) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:786) at com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:778) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:618) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:371) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:478) at com.google.gwt.dev.jjs.ast.js.JsniMethodRef.traverse(JsniMethodRef.java:69) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146) at com.google.gwt.dev.jjs.ast.JVisitor.acceptImmutable(JVisitor.java:154) at com.google.gwt.dev.jjs.ast.js.JsniMethodBody.traverse(JsniMethodBody.java:136) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) [ERROR] Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...) [ERROR] Unrecoverable exception, shutting down com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:56) at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:74) at java.lang.Thread.run(Thread.java:750) [ERROR] Not all permutation were compiled , completed (0/1)

my project is kinda old, using jars, and compiling in cmd.

I'm giving the compiler 36GB ram, compiling for only firefox, using draftCompile and much more, but nothing is working.

I'm also fairly new to GWT, and i'm really wondering how did the dev working on this specific project before me could compile 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/18ebe173-6371-4f1d-9424-10ce8d8f5bfdn%40googlegroups.com.