Google Web Toolkit: April 2025

Wednesday, April 30, 2025

Re: Log4j in doUnexpectedFailure

Thanks. This is very helpful.

The last link you posted implies that you're using tomcat, is that correct? It seems like this is more of a tomcat configuration problem then - could be worth tracking down in general, rather than hoping no other servlet library uses servlet apis for logging?

I know you say it's not an option - but we found JUL bridge to be our least bad long term option. We needed it for one specific library, but now I'd say there's maybe half a dozen edge cases it handles for us. FWIW - we moved to reload4j also as our code is 1.2 and we had no need of log4j 2.

The biggest issue is writing to application-specific log files. With the bridges I can get more info from ServletContext.log, including the web app context, but it's only outputting to the main Tomcat log, not to the application log as well. I am not understanding the docs well enough to see whether or how this can be changed.

On Wednesday, April 30, 2025 at 12:45:30 AM UTC-5 RobW wrote:

I know you say it's not an option - but we found JUL bridge to be our least bad long term option. We needed it for one specific library, but now I'd say there's maybe half a dozen edge cases it handles for us. FWIW - we moved to reload4j also as our code is 1.2 and we had no need of log4j 2.

On Tuesday, 29 April 2025 at 21:37:30 UTC+1 Gerard Keiser wrote:
The default implementation of AbstractRemoteServiceServlet#doUnexpectedFailure(Throwable) calls RPCServletUtils#writeResponseForUnexpectedFailure(ServletContext, HttpServletResponse, Throwable), which logs the error with ServletContext#log(String, Throwable). We would like to use Log4j instead. We generally try to avoid overriding methods in 3rd party libraries, but is there another way to swap out the logger? Setting up the JUL-to-Log4j bridge isn't a good option at the moment, making a wrapper that implements ServletContext seems much worse, and replacing the application server logger didn't help.

Thanks,
Gerard

--
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/68e19bcc-2679-4141-bc08-df4bd91f091en%40googlegroups.com.

Re: Log4j in doUnexpectedFailure

Thanks; that's quite helpful. I will try some more with the JUL bridge, and do the override if it doesn't work out still.

On Wed, Apr 30, 2025 at 12:46 AM 'RobW' via GWT Users <google-web-toolkit@googlegroups.com> wrote:

I know you say it's not an option - but we found JUL bridge to be our least bad long term option. We needed it for one specific library, but now I'd say there's maybe half a dozen edge cases it handles for us. FWIW - we moved to reload4j also as our code is 1.2 and we had no need of log4j 2.

On Tuesday, 29 April 2025 at 21:37:30 UTC+1 Gerard Keiser wrote:
The default implementation of AbstractRemoteServiceServlet#doUnexpectedFailure(Throwable) calls RPCServletUtils#writeResponseForUnexpectedFailure(ServletContext, HttpServletResponse, Throwable), which logs the error with ServletContext#log(String, Throwable). We would like to use Log4j instead. We generally try to avoid overriding methods in 3rd party libraries, but is there another way to swap out the logger? Setting up the JUL-to-Log4j bridge isn't a good option at the moment, making a wrapper that implements ServletContext seems much worse, and replacing the application server logger didn't help.

Thanks,
Gerard

--
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/238b9e33-97fa-4edd-8070-0d383ee85621n%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/CABTtZZCk7e6O3zbA4NjTr9XvC7FMJOXH2hCTiYMXd2H4U1hOFw%40mail.gmail.com.

Tuesday, April 29, 2025

Re: Log4j in doUnexpectedFailure

I know you say it's not an option - but we found JUL bridge to be our least bad long term option. We needed it for one specific library, but now I'd say there's maybe half a dozen edge cases it handles for us. FWIW - we moved to reload4j also as our code is 1.2 and we had no need of log4j 2.

On Tuesday, 29 April 2025 at 21:37:30 UTC+1 Gerard Keiser wrote:

The default implementation of AbstractRemoteServiceServlet#doUnexpectedFailure(Throwable) calls RPCServletUtils#writeResponseForUnexpectedFailure(ServletContext, HttpServletResponse, Throwable), which logs the error with ServletContext#log(String, Throwable). We would like to use Log4j instead. We generally try to avoid overriding methods in 3rd party libraries, but is there another way to swap out the logger? Setting up the JUL-to-Log4j bridge isn't a good option at the moment, making a wrapper that implements ServletContext seems much worse, and replacing the application server logger didn't help.

Thanks,
Gerard

--
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/238b9e33-97fa-4edd-8070-0d383ee85621n%40googlegroups.com.

Re: IEEE 754 mode for Java

> I meant that IntelliJ run configuration for JUnit has an option forkmode and I am pretty sure the maven plugin also has an option for JVM forking. For example you can configure that every test method should run in a forked VM in IntelliJ. By default it doesn't do that.

Ah, cool, thanks. I see that option now.

With it on, I get different results again. Different to maven, different to no fork, and different to JavaScript.

And if I run it through Maven with "mvn test -DforkCount=1 -DreuseForks=false", I get results that are completely different again.

They are still consistent though. Ie: Running it multiple times, always gets the same results.

On Tuesday, 29 April 2025 at 8:34:25 pm UTC+10 Jens wrote:

> Maybe the result slightly changes if JVM decides to optimize a hot code path in case the JVM is reused. You might want to check how maven and your intellij run configuration are configured in terms of JVM forking.

IntelliJ seems to add the options:
-Dkotlinx.coroutines.debug.enable.creation.stack.trace=false -Ddebugger.agent.enable.coroutines=true -Dkotlinx.coroutines.debug.enable.flows.stack.trace=true -Dkotlinx.coroutines.debug.enable.mutable.state.flows.stack.trace=true -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8

So I added those to MAVEN_OPTS, but it didn't seem to make any difference. I also tried adding @NotThreadSafe to my test suite, again no difference.

I meant that IntelliJ run configuration for JUnit has an option forkmode and I am pretty sure the maven plugin also has an option for JVM forking. For example you can configure that every test method should run in a forked VM in IntelliJ. By default it doesn't do that.

-- 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/0cb31590-9d03-488b-894c-92492a0395ban%40googlegroups.com.

Re: Log4j in doUnexpectedFailure

It looks like AbstractRemoteServiceServlet's doUnexpectedFailure method is protected and non-final - it definitely looks appropriate here to override that and follow the same steps. You could also log and then delegate to super.doUnexpectedFailure if you're concerned about changes happening in AbstractRemoteServiceServlet. Such changes are pretty unlikely though - the callsite for that method (in doPost()) explicitly says that doUnexpectedFailure exists to "give a subclass a change to either handle the exception or rethrow it".

Note also that it is totally appropriate to not call super and implement your own logic, as long as you somehow signal failure back to the client. RPCServletUtils.writeResponseForUnexpectedFailure is going to just send back a generic 500 since this is after all an unexpected failure and one that can't take the normal approach of telling the client what happened.

The last link you posted implies that you're using tomcat, is that correct? It seems like this is more of a tomcat configuration problem then - could be worth tracking down in general, rather than hoping no other servlet library uses servlet apis for logging?

Finally, please note that this is not the only way that GWT-RPC is going to call context.log() - see RPCServletUtils.writeResponse for example.

On Tuesday, April 29, 2025 at 3:37:30 PM UTC-5 Gerard Keiser wrote:

The default implementation of AbstractRemoteServiceServlet#doUnexpectedFailure(Throwable) calls RPCServletUtils#writeResponseForUnexpectedFailure(ServletContext, HttpServletResponse, Throwable), which logs the error with ServletContext#log(String, Throwable). We would like to use Log4j instead. We generally try to avoid overriding methods in 3rd party libraries, but is there another way to swap out the logger? Setting up the JUL-to-Log4j bridge isn't a good option at the moment, making a wrapper that implements ServletContext seems much worse, and replacing the application server logger didn't help.

Thanks,
Gerard

--
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/1e4c8009-49bc-41d4-82e6-d47e4bd9c6cfn%40googlegroups.com.

Log4j in doUnexpectedFailure

The default implementation of AbstractRemoteServiceServlet#doUnexpectedFailure(Throwable) calls RPCServletUtils#writeResponseForUnexpectedFailure(ServletContext, HttpServletResponse, Throwable), which logs the error with ServletContext#log(String, Throwable). We would like to use Log4j instead. We generally try to avoid overriding methods in 3rd party libraries, but is there another way to swap out the logger? Setting up the JUL-to-Log4j bridge isn't a good option at the moment, making a wrapper that implements ServletContext seems much worse, and replacing the application server logger didn't help.

Thanks,

Gerard

--
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/73811356-0d2d-4288-98bb-dfb88e6d5043n%40googlegroups.com.

Re: IEEE 754 mode for Java

> Maybe the result slightly changes if JVM decides to optimize a hot code path in case the JVM is reused. You might want to check how maven and your intellij run configuration are configured in terms of JVM forking.

IntelliJ seems to add the options:
-Dkotlinx.coroutines.debug.enable.creation.stack.trace=false -Ddebugger.agent.enable.coroutines=true -Dkotlinx.coroutines.debug.enable.flows.stack.trace=true -Dkotlinx.coroutines.debug.enable.mutable.state.flows.stack.trace=true -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8

So I added those to MAVEN_OPTS, but it didn't seem to make any difference. I also tried adding @NotThreadSafe to my test suite, again no difference.

I meant that IntelliJ run configuration for JUnit has an option forkmode and I am pretty sure the maven plugin also has an option for JVM forking. For example you can configure that every test method should run in a forked VM in IntelliJ. By default it doesn't do that.

-- 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/a63c46b8-278c-4956-81a5-69db52985fa3n%40googlegroups.com.

Monday, April 28, 2025

Re: IEEE 754 mode for Java

> Amazing game! Congratulations

Thanks! Just a fun side project that I'm probably getting too carried away with.

> Maybe the result slightly changes if JVM decides to optimize a hot code path in case the JVM is reused. You might want to check how maven and your intellij run configuration are configured in terms of JVM forking.

IntelliJ seems to add the options:

-Dkotlinx.coroutines.debug.enable.creation.stack.trace=false -Ddebugger.agent.enable.coroutines=true -Dkotlinx.coroutines.debug.enable.flows.stack.trace=true -Dkotlinx.coroutines.debug.enable.mutable.state.flows.stack.trace=true -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8

So I added those to MAVEN_OPTS, but it didn't seem to make any difference. I also tried adding @NotThreadSafe to my test suite, again no difference.

> Looks like a good game, I didn't see an option for 3d rendering, maybe still not practical in a browser

Thanks! Yes, 3D is very easy in the browser. My game actually uses WebGL, so it's using the 3D card, just rendering a 2D scene. Only reason I didn't do 3D is because my 3D modelling skills are non existent. Plus I wanted to keep the game lightweight and dynamic, so every track has different cars and scenery. 2D is simple sprites, 3D is meshes and lots of textures.

On Tuesday, 29 April 2025 at 3:31:29 am UTC+10 Tim Macpherson wrote:

Looks like a good game, I didn't see an option for 3d rendering, maybe still not practical in a browser

Yahoo Mail: Search, Organize, Conquer

On Mon, Apr 28, 2025 at 4:06 PM, Jens
<jens.ne...@gmail.com> wrote:

- The failures always occur with races that have computer opponents (which is about 30% of the races).
- The failures always consistently fail with the same results. Ie: If I run a test with mvn test, I'll always get one result. If I run the same test with IntelliJ, I'll always get the same different result.

Maybe the result slightly changes if JVM decides to optimize a hot code path in case the JVM is reused. You might want to check how maven and your intellij run configuration are configured in terms of JVM forking.

-- 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-tool...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/google-web-toolkit/473c676b-53e7-4544-a0a7-53816d5a5eean%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/43e40722-d4d3-4e42-afa7-42229edef828n%40googlegroups.com.

Re: IEEE 754 mode for Java

- The failures always occur with races that have computer opponents (which is about 30% of the races).
- The failures always consistently fail with the same results. Ie: If I run a test with mvn test, I'll always get one result. If I run the same test with IntelliJ, I'll always get the same different result.

Maybe the result slightly changes if JVM decides to optimize a hot code path in case the JVM is reused. You might want to check how maven and your intellij run configuration are configured in terms of JVM forking.

-- J.

https://groups.google.com/d/msgid/google-web-toolkit/473c676b-53e7-4544-a0a7-53816d5a5eean%40googlegroups.com

Re: IEEE 754 mode for Java

- The failures always occur with races that have computer opponents (which is about 30% of the races).
- The failures always consistently fail with the same results. Ie: If I run a test with mvn test, I'll always get one result. If I run the same test with IntelliJ, I'll always get the same different result.

-- 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/473c676b-53e7-4544-a0a7-53816d5a5eean%40googlegroups.com.

Re: IEEE 754 mode for Java

Amazing game! Congratulations

On Mon, Apr 28, 2025 at 5:18 AM Craig Mitchell <mail@craig-mitchell.com> wrote:

If interested, my situation is a car racing game. The graphics code is in the client module, and the logic code is in the shared module. The player plays in the browser, and once finished, their input controls are sent to the server, that then replays the race in the logic code to make sure they didn't cheat.

Thus, the logic code is run in JavaScript in the browser, and in Java on the server.

In addition to that, players also race against replays of other players. Those replays are generated in the browser, again using the logic code from the recorded player inputs.

JavaScript has been rock solid, across all browsers and platforms (PC / Mac / Android / iPhone / Smart TVs, Tesla browser / ...) The logic code always outputs the same results.

Java not so much.

There is a pattern however:
- The failures always occur with races that have computer opponents (which is about 30% of the races).
- The failures always consistently fail with the same results. Ie: If I run a test with mvn test, I'll always get one result. If I run the same test with IntelliJ, I'll always get the same different result.

I'm trawling through the computer opponent logic code to see if I can see anything suspicious.

I have avoided obvious things like:
- Not using Math.sin, Math.cos, Math.atan, etc. as those return different results based on the platform.
- Not using floats, as they are not suported by JavaScript.

As Colin suggested, I'm also implementing the tests with GWTTestCase, to see if they pass or not.

The game if you're curious: https://drift.team/

Cheers.

On Monday, 28 April 2025 at 5:01:33 pm UTC+10 RobW wrote:
If your solution relies on absolute accuracy across different languages and machines but you're using floating point I'd say you are setting yourself up for some major heartache and issues. Even with IEEE 754, and supposedly strict rules on rounding I wouldn't trust the fidelity across machines. Do you really need to do the math both on the server in Java and in the browser? Pick one and use that maybe. Or, if you need complete fidelity, use something other than floating point - integer arithmetic or maybe BigDecimal on the server.

On Sunday, 27 April 2025 at 13:39:06 UTC+1 Thomas Broyer wrote:
On Sunday, April 27, 2025 at 2:06:11 AM UTC+2 ma...@craig-mitchell.com wrote:
I asked AI about my problem, and it told me it was due to Java not following the IEEE 754 standard and I have to expect inconsistant results. However, I don't know if that's correct. There are people saying Java does follow IEEE 754 and others that say it doesn't.

It does: https://docs.oracle.com/javase/specs/jls/se24/html/jls-4.html#jls-4.2.3

--
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/bfcc50a6-a012-4bc9-a5b1-10430e63ea13n%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%2BkiFsfM1gaG1cWahAqgOYRuJuXUy8sKbnMcvp0xOpsdNn%3Dbtg%40mail.gmail.com.

Re: IEEE 754 mode for Java

If interested, my situation is a car racing game. The graphics code is in the client module, and the logic code is in the shared module. The player plays in the browser, and once finished, their input controls are sent to the server, that then replays the race in the logic code to make sure they didn't cheat.

Thus, the logic code is run in JavaScript in the browser, and in Java on the server.

In addition to that, players also race against replays of other players. Those replays are generated in the browser, again using the logic code from the recorded player inputs.

JavaScript has been rock solid, across all browsers and platforms (PC / Mac / Android / iPhone / Smart TVs, Tesla browser / ...) The logic code always outputs the same results.

Java not so much.

There is a pattern however:

- The failures always occur with races that have computer opponents (which is about 30% of the races).

- The failures always consistently fail with the same results. Ie: If I run a test with mvn test, I'll always get one result. If I run the same test with IntelliJ, I'll always get the same different result.

I'm trawling through the computer opponent logic code to see if I can see anything suspicious.

I have avoided obvious things like:

- Not using Math.sin, Math.cos, Math.atan, etc. as those return different results based on the platform.

- Not using floats, as they are not suported by JavaScript.

As Colin suggested, I'm also implementing the tests with GWTTestCase, to see if they pass or not.

The game if you're curious: https://drift.team/

Cheers.

On Monday, 28 April 2025 at 5:01:33 pm UTC+10 RobW wrote:

If your solution relies on absolute accuracy across different languages and machines but you're using floating point I'd say you are setting yourself up for some major heartache and issues. Even with IEEE 754, and supposedly strict rules on rounding I wouldn't trust the fidelity across machines. Do you really need to do the math both on the server in Java and in the browser? Pick one and use that maybe. Or, if you need complete fidelity, use something other than floating point - integer arithmetic or maybe BigDecimal on the server.

On Sunday, 27 April 2025 at 13:39:06 UTC+1 Thomas Broyer wrote:
On Sunday, April 27, 2025 at 2:06:11 AM UTC+2 ma...@craig-mitchell.com wrote:
I asked AI about my problem, and it told me it was due to Java not following the IEEE 754 standard and I have to expect inconsistant results. However, I don't know if that's correct. There are people saying Java does follow IEEE 754 and others that say it doesn't.

It does: https://docs.oracle.com/javase/specs/jls/se24/html/jls-4.html#jls-4.2.3

--
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/bfcc50a6-a012-4bc9-a5b1-10430e63ea13n%40googlegroups.com.

Re: IEEE 754 mode for Java

If your solution relies on absolute accuracy across different languages and machines but you're using floating point I'd say you are setting yourself up for some major heartache and issues. Even with IEEE 754, and supposedly strict rules on rounding I wouldn't trust the fidelity across machines. Do you really need to do the math both on the server in Java and in the browser? Pick one and use that maybe. Or, if you need complete fidelity, use something other than floating point - integer arithmetic or maybe BigDecimal on the server.

On Sunday, 27 April 2025 at 13:39:06 UTC+1 Thomas Broyer wrote:

On Sunday, April 27, 2025 at 2:06:11 AM UTC+2 ma...@craig-mitchell.com wrote:
I asked AI about my problem, and it told me it was due to Java not following the IEEE 754 standard and I have to expect inconsistant results. However, I don't know if that's correct. There are people saying Java does follow IEEE 754 and others that say it doesn't.

It does: https://docs.oracle.com/javase/specs/jls/se24/html/jls-4.html#jls-4.2.3

--
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/1f66e243-2d95-475e-8fcc-cc86ef0ec1e5n%40googlegroups.com.

Sunday, April 27, 2025

Re: Does GWTTestCase still work?

Thanks Colin. I wasn't aware of the "Suite" naming convention.

So, to summarise. Either:

- Put "Suite" or "SuiteNoBrowser" at the end of the test class name, or

- Add the test class directly as an include in the client pom.xml, in the gwt-maven-plugin.

Now working great!

On Sunday, 27 April 2025 at 10:30:10 pm UTC+10 Colin Alworth wrote:

When using maven, running from the command line should be "mvn test". With the plugin you are using, it is assumed you are using a test suite - this is not required, but scales better. If you only need to run a single test, you can modify this includes.

https://tbroyer.github.io/gwt-maven-plugin/test-mojo.html#includes

For example in your project with MyTests (note: that wouldn't run even in a non-gwt project from maven, the default pattern is *Test), you could add this:
<includes>
<include>test/craig/MyTests.java</include>
</includes>

When I do that, having built the sample as you describe, the tests passes with mvn test:
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running test.craig.MyTests
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13.96 s -- in test.craig.MyTests
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

When running from IJ, it doesnt automatically add sources to the classpath as gwt:test does, so you may just want to call the maven goal directly instead. I recall that it is possible to configure Maven/IJ to run tests "normally", but can't quickly spot what that would be.

On Sunday, April 27, 2025 at 12:18:17 AM UTC-5 ma...@craig-mitchell.com wrote:
When running from the command line, I forgot to add all the items to the class path. Once I did that, I got the same error IntelliJ did:

There was 1 error:
1) testSimple(test.craig.MyTests)com.google.gwt.junit.JUnitFatalLaunchException: The test class 'test.craig.MyTests' was not found in module 'test.craig.App'; no compilation unit for that type was seen
at com.google.gwt.junit.JUnitShell.checkTestClassInCurrentModule(JUnitShell.java:741)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1360)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1316)
at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:679)
at com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:421)
at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:247)

FAILURES!!!
Tests run: 1, Failures: 0, Errors: 1

On Sunday, 27 April 2025 at 2:54:36 pm UTC+10 Craig Mitchell wrote:
I created a demo project with https://github.com/NaluKit/gwt-maven-springboot-archetype with the params:
- modular-springboot-webapp
- groupId: test.craig
- artifactId: testing
- module-short-name app: tc

Added JUnit to the client pom:
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.2</version>
<scope>test</scope>
</dependency>

Created a simple test in the client module (in src/test/java/test/craig/MyTests.java):
public class MyTests extends GWTTestCase {
@Override
public String getModuleName() {
return "test.craig.App";
}
public void testSimple() {
assertTrue( true );
}
}

Tried to run it in IntelliJ, but got the error:
com.google.gwt.junit.JUnitFatalLaunchException: The test class 'test.craig.MyTests' was not found in module 'test.craig.App'; no compilation unit for that type was seen

Tried to compile and run it from the command line:
java junit.textui.TestRunner test.craig.MyTests

But that returned:
Error: Could not find or load main class junit.textui.TestRunner
Caused by: java.lang.ClassNotFoundException: junit.textui.TestRunner

I thought I was following the instructions in https://www.gwtproject.org/doc/latest/DevGuideTesting.html but obviously doing something wrong.

Any help is much appreciated.

--
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/b47f40a3-f509-4424-bde7-a15316096b24n%40googlegroups.com.

Re: IEEE 754 mode for Java

On Sunday, April 27, 2025 at 2:06:11 AM UTC+2 ma...@craig-mitchell.com wrote:

I asked AI about my problem, and it told me it was due to Java not following the IEEE 754 standard and I have to expect inconsistant results. However, I don't know if that's correct. There are people saying Java does follow IEEE 754 and others that say it doesn't.

It does: https://docs.oracle.com/javase/specs/jls/se24/html/jls-4.html#jls-4.2.3

--
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/3a5d5783-ea00-4cf8-a1fc-7a441bfaa942n%40googlegroups.com.

Re: Does GWTTestCase still work?

When using maven, running from the command line should be "mvn test". With the plugin you are using, it is assumed you are using a test suite - this is not required, but scales better. If you only need to run a single test, you can modify this includes.

https://tbroyer.github.io/gwt-maven-plugin/test-mojo.html#includes

For example in your project with MyTests (note: that wouldn't run even in a non-gwt project from maven, the default pattern is *Test), you could add this:
<includes>
<include>test/craig/MyTests.java</include>
</includes>

When I do that, having built the sample as you describe, the tests passes with mvn test:
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running test.craig.MyTests
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13.96 s -- in test.craig.MyTests
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

When running from IJ, it doesnt automatically add sources to the classpath as gwt:test does, so you may just want to call the maven goal directly instead. I recall that it is possible to configure Maven/IJ to run tests "normally", but can't quickly spot what that would be.

On Sunday, April 27, 2025 at 12:18:17 AM UTC-5 ma...@craig-mitchell.com wrote:

When running from the command line, I forgot to add all the items to the class path. Once I did that, I got the same error IntelliJ did:

There was 1 error:
1) testSimple(test.craig.MyTests)com.google.gwt.junit.JUnitFatalLaunchException: The test class 'test.craig.MyTests' was not found in module 'test.craig.App'; no compilation unit for that type was seen
at com.google.gwt.junit.JUnitShell.checkTestClassInCurrentModule(JUnitShell.java:741)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1360)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1316)
at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:679)
at com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:421)
at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:247)

FAILURES!!!
Tests run: 1, Failures: 0, Errors: 1

On Sunday, 27 April 2025 at 2:54:36 pm UTC+10 Craig Mitchell wrote:
I created a demo project with https://github.com/NaluKit/gwt-maven-springboot-archetype with the params:
- modular-springboot-webapp
- groupId: test.craig
- artifactId: testing
- module-short-name app: tc

Added JUnit to the client pom:
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.2</version>
<scope>test</scope>
</dependency>

Created a simple test in the client module (in src/test/java/test/craig/MyTests.java):
public class MyTests extends GWTTestCase {
@Override
public String getModuleName() {
return "test.craig.App";
}
public void testSimple() {
assertTrue( true );
}
}

Tried to run it in IntelliJ, but got the error:
com.google.gwt.junit.JUnitFatalLaunchException: The test class 'test.craig.MyTests' was not found in module 'test.craig.App'; no compilation unit for that type was seen

Tried to compile and run it from the command line:
java junit.textui.TestRunner test.craig.MyTests

But that returned:
Error: Could not find or load main class junit.textui.TestRunner
Caused by: java.lang.ClassNotFoundException: junit.textui.TestRunner

I thought I was following the instructions in https://www.gwtproject.org/doc/latest/DevGuideTesting.html but obviously doing something wrong.

Any help is much appreciated.

--
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/0ec96ebe-f942-4c52-b914-3c42d9b69015n%40googlegroups.com.

Re: Does GWTTestCase still work?

What does your test/craig/App.gwt.xml look like? Does its <source> include MyTests.java?

On Sunday, April 27, 2025 at 7:18:17 AM UTC+2 ma...@craig-mitchell.com wrote:

When running from the command line, I forgot to add all the items to the class path. Once I did that, I got the same error IntelliJ did:

There was 1 error:
1) testSimple(test.craig.MyTests)com.google.gwt.junit.JUnitFatalLaunchException: The test class 'test.craig.MyTests' was not found in module 'test.craig.App'; no compilation unit for that type was seen
at com.google.gwt.junit.JUnitShell.checkTestClassInCurrentModule(JUnitShell.java:741)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1360)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1316)
at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:679)
at com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:421)
at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:247)

FAILURES!!!
Tests run: 1, Failures: 0, Errors: 1

On Sunday, 27 April 2025 at 2:54:36 pm UTC+10 Craig Mitchell wrote:
I created a demo project with https://github.com/NaluKit/gwt-maven-springboot-archetype with the params:
- modular-springboot-webapp
- groupId: test.craig
- artifactId: testing
- module-short-name app: tc

Added JUnit to the client pom:
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.2</version>
<scope>test</scope>
</dependency>

Created a simple test in the client module (in src/test/java/test/craig/MyTests.java):
public class MyTests extends GWTTestCase {
@Override
public String getModuleName() {
return "test.craig.App";
}
public void testSimple() {
assertTrue( true );
}
}

Tried to run it in IntelliJ, but got the error:
com.google.gwt.junit.JUnitFatalLaunchException: The test class 'test.craig.MyTests' was not found in module 'test.craig.App'; no compilation unit for that type was seen

Tried to compile and run it from the command line:
java junit.textui.TestRunner test.craig.MyTests

But that returned:
Error: Could not find or load main class junit.textui.TestRunner
Caused by: java.lang.ClassNotFoundException: junit.textui.TestRunner

I thought I was following the instructions in https://www.gwtproject.org/doc/latest/DevGuideTesting.html but obviously doing something wrong.

Any help is much appreciated.

--
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/d51a2bfb-a5b3-445e-8c47-352091f6e943n%40googlegroups.com.

Saturday, April 26, 2025

Re: Does GWTTestCase still work?

When running from the command line, I forgot to add all the items to the class path. Once I did that, I got the same error IntelliJ did:

There was 1 error:
1) testSimple(test.craig.MyTests)com.google.gwt.junit.JUnitFatalLaunchException: The test class 'test.craig.MyTests' was not found in module 'test.craig.App'; no compilation unit for that type was seen
at com.google.gwt.junit.JUnitShell.checkTestClassInCurrentModule(JUnitShell.java:741)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1360)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1316)
at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:679)
at com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:421)
at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:247)

FAILURES!!!
Tests run: 1, Failures: 0, Errors: 1

On Sunday, 27 April 2025 at 2:54:36 pm UTC+10 Craig Mitchell wrote:

I created a demo project with https://github.com/NaluKit/gwt-maven-springboot-archetype with the params:
- modular-springboot-webapp
- groupId: test.craig
- artifactId: testing
- module-short-name app: tc

Added JUnit to the client pom:
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.2</version>
<scope>test</scope>
</dependency>

Created a simple test in the client module (in src/test/java/test/craig/MyTests.java):
public class MyTests extends GWTTestCase {
@Override
public String getModuleName() {
return "test.craig.App";
}
public void testSimple() {
assertTrue( true );
}
}

Tried to run it in IntelliJ, but got the error:
com.google.gwt.junit.JUnitFatalLaunchException: The test class 'test.craig.MyTests' was not found in module 'test.craig.App'; no compilation unit for that type was seen

Tried to compile and run it from the command line:
java junit.textui.TestRunner test.craig.MyTests

But that returned:
Error: Could not find or load main class junit.textui.TestRunner
Caused by: java.lang.ClassNotFoundException: junit.textui.TestRunner

I thought I was following the instructions in https://www.gwtproject.org/doc/latest/DevGuideTesting.html but obviously doing something wrong.

Any help is much appreciated.

--
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/48c6f70f-8712-4a89-8f74-51fd25632d48n%40googlegroups.com.

Does GWTTestCase still work?

I created a demo project with https://github.com/NaluKit/gwt-maven-springboot-archetype with the params:

- modular-springboot-webapp

- groupId: test.craig
- artifactId: testing
- module-short-name app: tc

Added JUnit to the client pom:

<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.2</version>
<scope>test</scope>
</dependency>

Created a simple test in the client module (in src/test/java/test/craig/MyTests.java):

public class MyTests extends GWTTestCase {
@Override
public String getModuleName() {
return "test.craig.App";
}
public void testSimple() {
assertTrue( true );
}
}

Tried to run it in IntelliJ, but got the error:

com.google.gwt.junit.JUnitFatalLaunchException: The test class 'test.craig.MyTests' was not found in module 'test.craig.App'; no compilation unit for that type was seen

Tried to compile and run it from the command line:

java junit.textui.TestRunner test.craig.MyTests

But that returned:

Error: Could not find or load main class junit.textui.TestRunner
Caused by: java.lang.ClassNotFoundException: junit.textui.TestRunner

I thought I was following the instructions in https://www.gwtproject.org/doc/latest/DevGuideTesting.html but obviously doing something wrong.

Any help is much appreciated.

--
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/d9864a10-bb79-4a86-b6e2-b458ba8c0bf2n%40googlegroups.com.

Re: IEEE 754 mode for Java

You are correct, not really a GWT question. Apologies. Just a by product of using GWT.

> Can you give an example of the computation you're doing

This is my problem at the moment. I haven't been able to replicate it in a simple example. Trying something like:

double test = 12345678d;
for (int i = 1; i < 1_000_000; i++) {
if (i % 2 == 0) {
test = test * (double)i;
} else {
test = test / (double)i;
}
}

Gives 15473.01664039943 in all cases. In my real world test, there are thousands of lines of code.

> Also is there any chance that your tests are recognized by the compiler to be operations on constants, so the work is all being done at compile time rather than letting the browser actually do any work?

Obsolutely there is. I asked AI about my problem, and it told me it was due to Java not following the IEEE 754 standard and I have to expect inconsistant results. However, I don't know if that's correct. There are people saying Java does follow IEEE 754 and others that say it doesn't.

> Which browsers do you test with - does HtmlUnit pass these as well?

I've checked Chrome, Edge, and Firefox. All give the same result. I haven't tried HtmlUnit yet (I'll implement some GWTTestCase's now).

On Sunday, 27 April 2025 at 9:44:32 am UTC+10 Colin Alworth wrote:

(Sounds like this isn't actually a gwt question at all, but a java one, since gwt apparently is "right" where Java is wrong?)

Can you give an example of the computation you're doing - like a series of multiply/add/etc operations, or using Math/StrictMath and friends?

Also is there any chance that your tests are recognized by the compiler to be operations on constants, so the work is all being done at compile time rather than letting the browser actually do any work?

Which browsers do you test with - does HtmlUnit pass these as well?

--
Colin Alworth
co...@colinalworth.com

On Sat, Apr 26, 2025, at 6:24 PM, Craig Mitchell wrote:
I have some code that does millions of chained multiplications and divisions with doubles.

When I compile the code with GWT to Javascript, I get consistent results, no matter what the browser. I believe this is because Javascript follows the IEEE 754 standard.

However, running the same code in Java does not get consistent results. Not only are the results different from Javascript, they are different based on how I run the tests. Ie: Running from IntelliJ's JUnit runner vs running with "mvn test" gives different results.

I would like the results from Java to match the results from JavaScript (follow the IEEE 754 standard).

I'm on Windows, running Java Temurin 21.0.5 64-Bit.

Has anyone else faced this problem? Any ideas for a solution?

--
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/fde958f6-b9d7-4ff3-8c43-59c8cf0214cbn%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/e21d0e41-c297-4cf6-b1e2-6cc00f171b49n%40googlegroups.com.

Re: IEEE 754 mode for Java

(Sounds like this isn't actually a gwt question at all, but a java one, since gwt apparently is "right" where Java is wrong?)

Can you give an example of the computation you're doing - like a series of multiply/add/etc operations, or using Math/StrictMath and friends?

Also is there any chance that your tests are recognized by the compiler to be operations on constants, so the work is all being done at compile time rather than letting the browser actually do any work?

Which browsers do you test with - does HtmlUnit pass these as well?

Colin Alworth

colin@colinalworth.com

On Sat, Apr 26, 2025, at 6:24 PM, Craig Mitchell wrote:

I have some code that does millions of chained multiplications and divisions with doubles.

When I compile the code with GWT to Javascript, I get consistent results, no matter what the browser. I believe this is because Javascript follows the IEEE 754 standard.

However, running the same code in Java does not get consistent results. Not only are the results different from Javascript, they are different based on how I run the tests. Ie: Running from IntelliJ's JUnit runner vs running with "mvn test" gives different results.

I would like the results from Java to match the results from JavaScript (follow the IEEE 754 standard).

I'm on Windows, running Java Temurin 21.0.5 64-Bit.

Has anyone else faced this problem? Any ideas for a solution?

--
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/fde958f6-b9d7-4ff3-8c43-59c8cf0214cbn%40googlegroups.com.

IEEE 754 mode for Java

I have some code that does millions of chained multiplications and divisions with doubles.

When I compile the code with GWT to Javascript, I get consistent results, no matter what the browser. I believe this is because Javascript follows the IEEE 754 standard.

However, running the same code in Java does not get consistent results. Not only are the results different from Javascript, they are different based on how I run the tests. Ie: Running from IntelliJ's JUnit runner vs running with "mvn test" gives different results.

I would like the results from Java to match the results from JavaScript (follow the IEEE 754 standard).

I'm on Windows, running Java Temurin 21.0.5 64-Bit.

Has anyone else faced this problem? Any ideas for a solution?

--
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/fde958f6-b9d7-4ff3-8c43-59c8cf0214cbn%40googlegroups.com.

Oracle demos Java on WebAssembly

Oracle recently showed off a demo where they used GraalVM to compile Java code to WebAssembly:

https://2025.wasm.io/sessions/the-future-of-write-once-run-anywhere-from-java-to-webassembly/

The demo is a Java compiler that runs in the browser (the browser needs to have WASM-GC support).

They seem to have some basic JS integration working with a JSNI-like interface where JavaScript is written inside annotations. There doesn't seem to be support for anything like overlay types or JSInterop at the moment. But they do seem to support passing Java functional interfaces into JavaScript as callbacks.

It's still early days, but maybe this could be the basis for GWT 4? :)

--
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/d8c0b4ab-3108-40ad-9313-28b9143cd1b1n%40googlegroups.com.

Thursday, April 24, 2025

Re: Migrating maven gwt plugin

On Thursday, April 24, 2025 at 12:55:05 PM UTC+2 simon....@infoshare-is.com wrote:

Having had a quick look through the source code of both the old and new plugins, it seem the new plugin does not support the "generateAsync" option that the old one did, and which generated the required Async code.

Was this a deliberate choice, and is there some way I can actually generate this code?

Yes, it's a deliberate choice. See https://tbroyer.github.io/gwt-maven-plugin/migrating.html and https://github.com/tbroyer/gwt-maven-plugin/issues/1#issuecomment-650133019

TL;DR: retrieve the code generated by gwt:generateAsync from before changing the plugin and commit it into your codebase.

--
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/76fa88cc-5c7d-460d-838c-f57704606e56n%40googlegroups.com.

Re: Migrating maven gwt plugin

I'd suggest one change at a time, so you can understand the differences - from the way you phrased the problem, it sounded like "the old GWT maven plugin stopped working" and the symptom of that was that you were missing your async RemoteService.

The reality is almost certainly that the ltgt gwt-maven-plugin does not have a goal to do your async RemoteService generation, so you "broke" it when you changed the plugin.

Instead, I suggest one of two things, either:

* First update GWT, work out the new failure you're encountering there, and then consider the gwt-maven-plugin change, or

* First change plugins (which will also require adding gwt-dev if you don't have it already), then update GWT.

https://github.com/gwt-maven-plugin/gwt-maven-plugin/issues/174 was the issue I was referencing that suggests that the old plugin doesn't work even with GWT 2.11 - it might make sense to double check that you're actually compiling with 2.11.0 (and thus the new groupId, org.gwtproject rather than com.google.gwt), or if you have a mixture of versions already on your classpath...

On Thursday, April 24, 2025 at 5:55:05 AM UTC-5 simon....@infoshare-is.com wrote:

The previous GWT version I was using was 2.11, and the only changes I made was adding javax.servlet-api, gwt-dev, and the new maven plugin,

<plugin>
<groupId>net.ltgt.gwt.maven</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.1.0</version>
<extensions>true</extensions>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test</goal>
</goals>
</execution>
</executions>
<configuration>
<moduleName>com.infoshare.clearcore.ClearCore</moduleName>
</configuration>
</plugin>

Having had a quick look through the source code of both the old and new plugins, it seem the new plugin does not support the "generateAsync" option that the old one did, and which generated the required Async code.

Was this a deliberate choice, and is there some way I can actually generate this code?

Simon

On Wednesday, April 23, 2025 at 4:31:06 PM UTC+1 Colin Alworth wrote:
Can you confirm what version of GWT last successfully worked for you? Did you change anything else at the same time?

The GWT 2.12.2 release changed very little over 2.12.1, so it seems likely that you made bigger changes than just this version bump. From the issue tracker, the old gwt-maven-plugin didnt work with GWT 2.11 either, so likely you changed from GWT 2.10 (or older), and possibly made other changes too?

What happens if you directly run the generateAsync goal, are there log messages that might give hints here?

On Wednesday, April 23, 2025 at 8:20:39 AM UTC-5 simon....@infoshare-is.com wrote:
With the release of GWT 2.12, the old (legacy) GWT maven plugin has stopped working, and I need to migrate to the new (tbroyer?) plugin.

As a result of this change, I am getting a lot of "cannot find symbol" errors:

cannot find symbol
symbol: class CCServiceAsync
location: package com.infoshare.clearcore.client.services

These appear to be the asynchronous services that the client uses to contact the backend, and that I think were previously generated by the "generateAsync" goal.

How do I get rid of these errors?

Simon

--
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/d7587258-acf8-4658-90a8-4e0e8723aef7n%40googlegroups.com.