Thursday, December 31, 2015

Re: It should be registered via or entry in your .gwt.xml ?

Looks like the element is missing from the dtd? https://gwt.googlesource.com/gwt.git/+/master/distro-source/core/src/gwt-module.dtd

On Wednesday, December 30, 2015 at 4:22:44 PM UTC-8, Thomas Broyer wrote:


On Thursday, December 31, 2015 at 12:45:11 AM UTC+1, cellepo wrote:
It doesn't look like <resource /> is a possible Element type in GWT 2.7?

I can add <source />, but when I add a <resource />...
The content of element type "module" must match "(inherits|source|public|super-source|entry-point|stylesheet|
 script|servlet|replace-with|generate-with|define-property|extend-property|set-property|set-property-fallback|
 clear-configuration-property|define-configuration-property|extend-configuration-property|set-configuration-
 property|property-provider|define-linker|add-linker|collapse-all-properties|collapse-property)*".
 
Unless I'm missing it, I don't see resource in that list, which seems to be why I can't add a <resource \>.  Unless I'm missing something? 

GWT doesn't validate the XML (using a DTD or schema); so this error message doesn't come from GWT.
…and yes the DTD is out of date. Patch welcome (real "schema" is defined in ModuleDefSchema class)
 

On Tuesday, March 24, 2015 at 1:58:01 PM UTC-4, MacWiz wrote:
Thanks Thomas.  Adding a <resource path="public" /> fixed these.  I thought I had tried that, but apparently not.  As far as the location of the images, we are discussing moving them, as you suggest.  They've been in our public area since the beginning of our GWT based work many years ago (starting with GWT v1.3, I believe.)

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Getting rid of Dev mode for future GWT releases

 
Javascript debuggers can do most of the things you are asking for. The Chrome debugger can do conditional breakpoints, restart a frame (drop-in-frame), and I think it can also override JS values just fine. It can break on any exception (caught and uncaught) and inside the browser dev tools you can hover certain expressions and see their value.

That's good news because then there may be hope that the Chrome API will let SDBG do at least a drop-to-frame.
 
Some of these features also work in IDEs using SDBG or plain IntelliJ. For example conditional break points just work in IntelliJ, but you have to use JS expressions as you are debugging JS and not Java (how should the IDE dynamically convert a any possible Java expression to a JS expression on the fly as the browser debugger only understands JS ?!). Never tried the drop-to-frame feature but I guess it might also work.

The IDE should be able to do this just as it does it for any other language it debugs. You don't have to provide your Java inspection expressions in JVM byte code, either. I know little about the exact GWT compiler architecture; yet, I would assume that it should be possible to give the compiler enough context such that it can translate an expression into the equivalent JavaScript. It does so during normal and during incremental compilation, so at least theoretically this should also be possible when debugging. The expression compiled this way could then be passed to the native debugger's API for dynamic evaluation.
  
By the way you would have the same issues with any language compiling to JS, not just GWT. The only exception might be Dart as there is a Dart VM for Chrome. But once you have compiled Dart to JS you are probably in the same situation as with GWT if you need to debug the JS code and use source maps.

This, IMHO, just goes to show that the integration between the IDE debugger and the JS browser runtime is not yet where it should be. If I run a JVM external to my IDE, even when running on a remote host, the debug API allows me to do all the things discussed before. It would be interesting to check how this works for other JVM-targeted languages (Jython, JRuby, Scala, ...). I know that in the early days of Scala Martin Odersky's team had similar trouble while trying to stay with the regular JDT in Eclipse. Debug stack frames revealed compiler internals and name manglings. It wasn't nice. It required significant investment into particularly the debugging environment to reach par with JDT for Java. I guess, lack of a similar investment is what we're observing now with SDM.

-- Axel 

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: ArrayIndexOutOfBoundsException in GWT Compiler for non-trivial type arg in RPC service parameter

I've now also checked this with GWT 2.8.0 compiled from commit ad8ed35116bf22efdfdcf6984a3a3d79e26ded04 with the following result:

Compiling module gwt.generics.bug.Gwt_generics_bug
   Computing all possible rebind results for 'gwt.generics.bug.client.GreetingService'
      Rebinding gwt.generics.bug.client.GreetingService
         Invoking generator com.google.gwt.user.rebind.rpc.ServiceInterfaceProxyGenerator
            [ERROR] Generator 'com.google.gwt.user.rebind.rpc.ServiceInterfaceProxyGenerator' threw an exception while rebinding 'gwt.generics.bug.client.GreetingService'
java.lang.ArrayIndexOutOfBoundsException: 1
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer.getFlowInfo(TypeParameterExposureComputer.java:420)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer.access$200(TypeParameterExposureComputer.java:40)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.getFlowInfo(TypeParameterExposureComputer.java:322)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.recordCausesExposure(TypeParameterExposureComputer.java:329)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.computeIndirectExposureCauses(TypeParameterExposureComputer.java:269)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.initializeExposure(TypeParameterExposureComputer.java:195)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.updateFlowInfo(TypeParameterExposureComputer.java:169)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer.computeTypeParameterExposure(TypeParameterExposureComputer.java:398)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.getFlowInfo(SerializableTypeOracleBuilder.java:1373)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.getTypeParameterExposure(SerializableTypeOracleBuilder.java:1006)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:1330)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:1176)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:1263)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:995)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:1337)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:1176)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:1263)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:995)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.build(SerializableTypeOracleBuilder.java:793)
at com.google.gwt.user.rebind.rpc.ProxyCreator.create(ProxyCreator.java:324)
at com.google.gwt.user.rebind.rpc.ServiceInterfaceProxyGenerator.generateIncrementally(ServiceInterfaceProxyGenerator.java:67)
at com.google.gwt.dev.javac.StandardGeneratorContext.runGeneratorIncrementally(StandardGeneratorContext.java:739)
at com.google.gwt.dev.cfg.RuleGenerateWith.realize(RuleGenerateWith.java:103)
at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.rebind(StandardRebindOracle.java:78)
at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:262)
at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:251)
at com.google.gwt.dev.PrecompilationContextCreator$1.getAllPossibleRebindAnswers(PrecompilationContextCreator.java:86)
at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.createStaticRebindExpression(UnifyAst.java:494)
at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.createRebindExpression(UnifyAst.java:464)
at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.handleMagicMethodCall(UnifyAst.java:589)
at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.endVisit(UnifyAst.java:294)
at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:259)
at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)
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.JModVisitor$ListContext.traverse(JModVisitor.java:88)
at com.google.gwt.dev.jjs.ast.JModVisitor.acceptWithInsertRemove(JModVisitor.java:331)
at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:92)
at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
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.JModVisitor.traverse(JModVisitor.java:361)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)
at com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:787)
at com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:779)
at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)
at com.google.gwt.dev.jjs.impl.UnifyAst.mainLoop(UnifyAst.java:1378)
at com.google.gwt.dev.jjs.impl.UnifyAst.exec(UnifyAst.java:876)
at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.unifyJavaAst(JavaToJavaScriptCompiler.java:1444)
at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.constructJavaAst(JavaToJavaScriptCompiler.java:1256)
at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:1176)
at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:256)
at com.google.gwt.dev.Precompile.precompile(Precompile.java:255)
at com.google.gwt.dev.Precompile.precompile(Precompile.java:202)
at com.google.gwt.dev.Precompile.precompile(Precompile.java:143)
at com.google.gwt.dev.Compiler.run(Compiler.java:197)
at com.google.gwt.dev.Compiler.run(Compiler.java:156)
at com.google.gwt.dev.Compiler$1.run(Compiler.java:117)
at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:55)
at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:50)
at com.google.gwt.dev.Compiler.main(Compiler.java:124)
   [ERROR] Errors in 'gwt/generics/bug/client/Gwt_generics_bug.java'
      [ERROR] Line 14: Failed to resolve 'gwt.generics.bug.client.GreetingService' via deferred binding

The problem seems to occur without change (other than a few line numbers being different in the stack trace).

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Wednesday, December 30, 2015

Re: It should be registered via or entry in your .gwt.xml ?



On Thursday, December 31, 2015 at 12:45:11 AM UTC+1, cellepo wrote:
It doesn't look like <resource /> is a possible Element type in GWT 2.7?

I can add <source />, but when I add a <resource />...
The content of element type "module" must match "(inherits|source|public|super-source|entry-point|stylesheet|
 script|servlet|replace-with|generate-with|define-property|extend-property|set-property|set-property-fallback|
 clear-configuration-property|define-configuration-property|extend-configuration-property|set-configuration-
 property|property-provider|define-linker|add-linker|collapse-all-properties|collapse-property)*".
 
Unless I'm missing it, I don't see resource in that list, which seems to be why I can't add a <resource \>.  Unless I'm missing something? 

GWT doesn't validate the XML (using a DTD or schema); so this error message doesn't come from GWT.
…and yes the DTD is out of date. Patch welcome (real "schema" is defined in ModuleDefSchema class)
 

On Tuesday, March 24, 2015 at 1:58:01 PM UTC-4, MacWiz wrote:
Thanks Thomas.  Adding a <resource path="public" /> fixed these.  I thought I had tried that, but apparently not.  As far as the location of the images, we are discussing moving them, as you suggest.  They've been in our public area since the beginning of our GWT based work many years ago (starting with GWT v1.3, I believe.)

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: It should be registered via or entry in your .gwt.xml ?

It doesn't look like <resource /> is a possible Element type in GWT 2.7?

I can add <source />, but when I add a <resource />...
The content of element type "module" must match "(inherits|source|public|super-source|entry-point|stylesheet|
 script|servlet|replace-with|generate-with|define-property|extend-property|set-property|set-property-fallback|
 clear-configuration-property|define-configuration-property|extend-configuration-property|set-configuration-
 property|property-provider|define-linker|add-linker|collapse-all-properties|collapse-property)*".
 
Unless I'm missing it, I don't see resource in that list, which seems to be why I can't add a <resource \>.  Unless I'm missing something? 

On Tuesday, March 24, 2015 at 1:58:01 PM UTC-4, MacWiz wrote:
Thanks Thomas.  Adding a <resource path="public" /> fixed these.  I thought I had tried that, but apparently not.  As far as the location of the images, we are discussing moving them, as you suggest.  They've been in our public area since the beginning of our GWT based work many years ago (starting with GWT v1.3, I believe.)

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Getting rid of Dev mode for future GWT releases

Well, except that JsInterop doesn't work in legacy dev mode.

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Getting rid of Dev mode for future GWT releases

In the past, I had encountered situations that the code works fine under Dev-Mode, but things went wrong in production mode, or acted differently in production mode.

At the beginning I had a hard time to switch from Dev-Mode to SDM. It took me "forever" to trace the bugs in my code. I found that things got a lot easier when I start new project from the very beginning using SDM.

More Java code in the Browser-end means more stuff GWT needs to convert into JavaScript. With using SDM, it encourages me to use more HTML / CSS / JavaScript instead of using GWT-Java only.

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Getting rid of Dev mode for future GWT releases


With that being said, I'd really love to reattain the level of productivity that I perceive with DevMode when it comes to debugging. SDBG just doesn't even come close to what I consider a real debugger. Stepping and watching variables is just by far not enough by today's IDE standards. I'm not an expert in native browser's JavaScript debugger capabilities. What keeps SDBG from providing the above list of features? If the compiler can map expressions to JavaScript, why can't SDM map those same expressions to something that the native JavaScript debugger can evaluate in-place for the current stack frame? Don't native JavaScript debuggers support conditional breakpoint? It would also come down to injecting the compiled expressions as breakpoint conditions. Don't native JavaScript debuggers support drop-to-frame? If not, can we expect this to change in the future? And what about the dynamic value changes in a native JavaScript debugger?

Javascript debuggers can do most of the things you are asking for. The Chrome debugger can do conditional breakpoints, restart a frame (drop-in-frame), and I think it can also override JS values just fine. It can break on any exception (caught and uncaught) and inside the browser dev tools you can hover certain expressions and see their value.

Some of these features also work in IDEs using SDBG or plain IntelliJ. For example conditional break points just work in IntelliJ, but you have to use JS expressions as you are debugging JS and not Java (how should the IDE dynamically convert a any possible Java expression to a JS expression on the fly as the browser debugger only understands JS ?!). Never tried the drop-to-frame feature but I guess it might also work.

AFAICT to make cross language debugging better, the source maps spec needs to be updated. Currently it seems to lack some information. For example I think it misses variable/parameter names, otherwise chrome debugger would probably show java names instead of JS names in the debugger. On the other hand it is handy that I can see JS variable names as that makes conditional breakpoints possible as I need to use JS expressions ;-)

By the way you would have the same issues with any language compiling to JS, not just GWT. The only exception might be Dart as there is a Dart VM for Chrome. But once you have compiled Dart to JS you are probably in the same situation as with GWT if you need to debug the JS code and use source maps.

-- 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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Remove unused code of external JavaScript file?

I have an external JavaScript file which I use using JSNI or JS Interop. 

I only use parts of this js file/ library. 

Is it possible to reduce the code of this external js file using GWT?

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: How to solve RPC error: Character Encoding is 'text/'. Expected 'UTF-8'

@Thomas: thanks for the tips, I will perform some logging of the Content-Type to see where it's coming from.​

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Getting rid of Dev mode for future GWT releases

@Axel: thanks for sharing and you are 100% spot on....
I also like to know if/how SDBG can be improved to benefit the full debugging power.... 

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Getting rid of Dev mode for future GWT releases

I've been using GWT now since about version 1.3. I chose it at the time because I really liked the manifesto and in particular the line "Java debugging is non-negotiable" (see http://www.gwtproject.org/makinggwtbetter.html). I admire folks who live without a debugger. Maybe they have the rigor to write code that simply doesn't require it. Or they have most of their code reside on the server, as one of the fellows wrote above. Or they have client code that for other reasons does not have to perform complicated tasks, maybe because the application is simple in its requirements.

However, when these factors are not given (and the GWT architecture has helped and guided us to exploit a lot more of the powerful browser platforms by shifting significant elements of our applications to the client), having a powerful debugger is a tool that makes me much more productive in my work. Features that I subsume under "powerful" are in particular (in decreasing degree of importance to me)

 - instant expression inspection (Eclipse: Shift-Ctrl-i to inspect the expression you just marked; works even on hover over fields and stack variables)
 - conditional breakpoints (provide a boolean expression and break if true; or break upon reaching an invocation count which I don't use that often)
 - drop to frame (after meticulously moving to where the problem is, hitting F6 one time too often...; no problem with drop to frame)
 - dynamically altering field and variable values (makes for a powerful couple in conjunction with drop to frame as it allows me to play "what if")

Inserting print statements may work for some. It doesn't if that code is a library that isn't easy to change. I don't want to have to unpack all sources first only in order to get "conditional breaking." Apart from that, the SDBG / GWT 2.7 combo is really "surprising" at times when I do an F6 to step over a line or expression and I end up in some Iterator or Collection implementation because that's how that for-loop is actually happening. Also, the subtle differences in behavior of F6 for multi-line statements between native Java/JVM and SDBG/SDM debugging increasingly annoy me. For Java, F6 goes to the next line, e.g., in a multi-line expression embedded in a statement. For SDM, F6 executes the entire statement. Bad luck if what you wanted to check was in the third line of your three lines long statement (and there is no drop to frame, either...). It really takes some getting used to and to me feels far from usable for my every-day work.

I really appreciate the speed that SDM provides. I've been using it since more than a year now, also together with SDBG in Eclipse. The incremental compile works like a charm, even when radically switching branches. There are clearly benefits in having the browser's JavaScript engine execute "the real thing" instead of running the client in the JVM and then having the costly browser integration that in several dimensions doesn't feel "real" (performance and stability, mostly). I also understand that browsers have changed in ways that make maintaining the existing DevMode plugin impossible.

With that being said, I'd really love to reattain the level of productivity that I perceive with DevMode when it comes to debugging. SDBG just doesn't even come close to what I consider a real debugger. Stepping and watching variables is just by far not enough by today's IDE standards. I'm not an expert in native browser's JavaScript debugger capabilities. What keeps SDBG from providing the above list of features? If the compiler can map expressions to JavaScript, why can't SDM map those same expressions to something that the native JavaScript debugger can evaluate in-place for the current stack frame? Don't native JavaScript debuggers support conditional breakpoint? It would also come down to injecting the compiled expressions as breakpoint conditions. Don't native JavaScript debuggers support drop-to-frame? If not, can we expect this to change in the future? And what about the dynamic value changes in a native JavaScript debugger?

Removal of DevMode without adequate improvements in SDM as outlined above, despite the promises of further performance improvements beyond 2.8, could be a valid reason to never upgrade beyond 2.8 anymore and keep a good old FF or IE version around that helps us with the heavy-lifting of debugging when it is really required.

Best,
-- Axel (sapsailing.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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Getting rid of Dev mode for future GWT releases

I don't think it's technically impossible to keep DevMode running. I was able to get DevMode to work using JavaFx as the browser instead of Chrome, and it seemed to work ok for basic stuff. It might also be possible to port the GWT UI framework to Elemental, and I've also been able to get Elemental to run in Java on top of JavaFx. I suppose it's even possible to make special versions of Firefox or Chrome that have the features needed to support the DevMode plugin directly.

I doubt that Google sees any value in maintaining DevMode for itself though. But I imagine if you have a support contract with an enterprise software firm selling GWT stuff like Vaadin or RedHat, you could probably bug them to do the necessary work to make it happen.

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

ArrayIndexOutOfBoundsException in GWT Compiler for non-trivial type arg in RPC service parameter

Hi there,

we've been encountering a strange compiler error when making special use of generics in GWT RPC service parameters. I've tried to boil it down to an example that you can find here as a ready-to-fail Eclipse project: https://drive.google.com/file/d/0BzPFwCC87Ht6VVVoQ0hjY3BoREU/view?usp=sharing

The exception the compiler throws is this:

Compiling module gwt.generics.bug.Gwt_generics_bug
   Computing all possible rebind results for 'gwt.generics.bug.client.GreetingService'
      Rebinding gwt.generics.bug.client.GreetingService
         Invoking generator com.google.gwt.user.rebind.rpc.ServiceInterfaceProxyGenerator
            [ERROR] Generator 'com.google.gwt.user.rebind.rpc.ServiceInterfaceProxyGenerator' threw an exception while rebinding 'gwt.generics.bug.client.GreetingService'
java.lang.ArrayIndexOutOfBoundsException: 1
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer.getFlowInfo(TypeParameterExposureComputer.java:420)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer.access$200(TypeParameterExposureComputer.java:40)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.getFlowInfo(TypeParameterExposureComputer.java:322)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.recordCausesExposure(TypeParameterExposureComputer.java:329)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.computeIndirectExposureCauses(TypeParameterExposureComputer.java:269)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.initializeExposure(TypeParameterExposureComputer.java:195)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer$TypeParameterFlowInfo.updateFlowInfo(TypeParameterExposureComputer.java:169)
at com.google.gwt.user.rebind.rpc.TypeParameterExposureComputer.computeTypeParameterExposure(TypeParameterExposureComputer.java:398)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.getFlowInfo(SerializableTypeOracleBuilder.java:1373)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.getTypeParameterExposure(SerializableTypeOracleBuilder.java:1006)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:1330)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:1176)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:1262)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:994)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:1337)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:1176)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:1262)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:994)
at com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.build(SerializableTypeOracleBuilder.java:792)
at com.google.gwt.user.rebind.rpc.ProxyCreator.create(ProxyCreator.java:324)
at com.google.gwt.user.rebind.rpc.ServiceInterfaceProxyGenerator.generateIncrementally(ServiceInterfaceProxyGenerator.java:67)
at com.google.gwt.dev.javac.StandardGeneratorContext.runGeneratorIncrementally(StandardGeneratorContext.java:754)
at com.google.gwt.dev.cfg.RuleGenerateWith.realize(RuleGenerateWith.java:160)
at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.rebind(StandardRebindOracle.java:79)
at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:276)
at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:265)
at com.google.gwt.dev.DistillerRebindPermutationOracle.getAllPossibleRebindAnswers(DistillerRebindPermutationOracle.java:87)
at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.createStaticRebindExpression(UnifyAst.java:485)
at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.createRebindExpression(UnifyAst.java:443)
at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.handleMagicMethodCall(UnifyAst.java:576)
at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.endVisit(UnifyAst.java:306)
at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:248)
at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:381)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:293)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:285)
at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:128)
at com.google.gwt.dev.jjs.ast.JExpressionStatement.traverse(JExpressionStatement.java:42)
at com.google.gwt.dev.jjs.ast.JModVisitor$ListContext.traverse(JModVisitor.java:95)
at com.google.gwt.dev.jjs.ast.JModVisitor.acceptWithInsertRemove(JModVisitor.java:351)
at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:92)
at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:381)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:293)
at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:149)
at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:145)
at com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:83)
at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:381)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:293)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:285)
at com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:600)
at com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:569)
at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:381)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:293)
at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:285)
at com.google.gwt.dev.jjs.impl.UnifyAst.mainLoop(UnifyAst.java:1505)
at com.google.gwt.dev.jjs.impl.UnifyAst.exec(UnifyAst.java:870)
at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler$Precompiler.unifyJavaAst(JavaToJavaScriptCompiler.java:1305)
at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler$Precompiler.constructJavaAst(JavaToJavaScriptCompiler.java:1038)
at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler$Precompiler.precompile(JavaToJavaScriptCompiler.java:954)
at com.google.gwt.dev.jjs.MonolithicJavaToJavaScriptCompiler.precompile(MonolithicJavaToJavaScriptCompiler.java:303)
at com.google.gwt.dev.jjs.JavaScriptCompiler.precompile(JavaScriptCompiler.java:38)
at com.google.gwt.dev.Precompile.precompile(Precompile.java:286)
at com.google.gwt.dev.Precompile.precompile(Precompile.java:229)
at com.google.gwt.dev.Precompile.precompile(Precompile.java:145)
at com.google.gwt.dev.Compiler.run(Compiler.java:206)
at com.google.gwt.dev.Compiler.run(Compiler.java:158)
at com.google.gwt.dev.Compiler$1.run(Compiler.java:120)
at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:55)
at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:50)
at com.google.gwt.dev.Compiler.main(Compiler.java:127)
   [ERROR] Errors in 'gwt/generics/bug/client/Gwt_generics_bug.java'
      [ERROR] Line 14: Failed to resolve 'gwt.generics.bug.client.GreetingService' via deferred binding

The issue occurs with version 2.7.0. I haven't gotten around to testing the same with the 2.8.0 snapshot that is available so far. It would be great if someone could try the project in that context.

To reproduce, I've started a GWT project from scratch in Eclipse, letting the project wizard do its thing, then adjusted the service method as follows:

    void useList(List<Pair<String, Boolean>> list);

Here is the Pair type signature:

    public class Pair<A, B> implements IsSerializable { ... }

with the usual, trivial implementation. The entry point is as simple as possible:

    public class Gwt_generics_bug implements EntryPoint {
        public void onModuleLoad() {
            GWT.create(GreetingService.class);
        }
    }

So far, this seems not special at all, and it is hard to see why the compiler would throw up on this. However, I debugged the compiler run (adding -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y to the VM arguments of the compiler launch) and found out that the compiler is having trouble with some seemingly unrelated type which happens to subclass Pair<A, B> as follows:

    public class SpecialPair<A extends BoundsInterface> extends Pair<TwoTypeArgInterface<?, A>, A> {
        public SpecialPair(TwoTypeArgInterface<?, A> a, A b) {
           super(a, b);
        }
    }

BoundsInterface is an empty marker interface, and TwoTypeArgInterface looks like this:

    public interface TwoTypeArgInterface<A extends InterfaceWithOneTypeArg<B>, B extends BoundsInterface> {}

and

    public interface InterfaceWithOneTypeArg<A extends BoundsInterface> {}

The compiler debug session suggests that the compiler confuses the formal parameter "A" of class SpecialPair, occurring with ordinal 0, with its use as actual type parameter in the instantiation of TwoTypeArgInterface where it occurs with index 1. This index 1 is then used to look up the formal parameter in SpecialPair's type parameter list, leading to the ArrayIndexOutOfBoundsException above.

I hope someone from the compiler team could have a look.

In the meantime, we have worked around the issue by more or less repeating the Pair<A, B> implementation for the SpecialPair use case such that subclassing the two-type-params class Pair<A, B> is not necessary for the SpecialPair implementation anymore. This lets the compile succeed for us. Still, I'm of the opinion that this is a compiler bug that should be fixed, if it isn't already in 2.8.0 in which case this would only be "for the record" ;-).

Thanks and best,
-- Axel

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: How to solve RPC error: Character Encoding is 'text/'. Expected 'UTF-8'

Somehow your HttpServletRequest is "broken" and returns "text/" as character encoding: https://github.com/gwtproject/gwt/blob/ad8ed35116bf22efdfdcf6984a3a3d79e26ded04/user/src/com/google/gwt/user/server/rpc/RPCServletUtils.java#L425
This might be due either to bad parsing somewhere (Tomcat?), a broken servlet filter that passes a broken request down the chain, or a ill-formed Content-Type header received by Tomcat. Logging of Content-Type request headers at different stages could help identify what's broken.

On Wednesday, December 30, 2015 at 5:00:09 PM UTC+1, Ed wrote:
Sometimes I do get the following stacktrace during RPC communication with the Tomcat backend.
Any idea how to solve this, and what could cause this ?
- Ed

javax.servlet.ServletException: Character Encoding is 'text/'. Expected 'UTF-8' 

    at com.google.gwt.user.server.rpc.RPCServletUtils.checkCharacterEncodingIgnoreCase(RPCServletUtils.java:439) 

    at com.google.gwt.user.server.rpc.RPCServletUtils.readContent(RPCServletUtils.java:212) 

    at com.google.gwt.user.server.rpc.RPCServletUtils.readContentAsGwtRpc(RPCServletUtils.java:252) 

    at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.readContent(AbstractRemoteServiceServlet.java:182)






--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

How to solve RPC error: Character Encoding is 'text/'. Expected 'UTF-8'

Sometimes I do get the following stacktrace during RPC communication with the Tomcat backend.
Any idea how to solve this, and what could cause this ?
- Ed

javax.servlet.ServletException: Character Encoding is 'text/'. Expected 'UTF-8' 

    at com.google.gwt.user.server.rpc.RPCServletUtils.checkCharacterEncodingIgnoreCase(RPCServletUtils.java:439) 

    at com.google.gwt.user.server.rpc.RPCServletUtils.readContent(RPCServletUtils.java:212) 

    at com.google.gwt.user.server.rpc.RPCServletUtils.readContentAsGwtRpc(RPCServletUtils.java:252) 

    at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.readContent(AbstractRemoteServiceServlet.java:182)






--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: JsInterop & 2.8.0-SNAPSHOT : calling Java Object in Javascript


Same behaviour with -draftCompile, I've also tried optimizationLevel to 0

Hmm and you are double sure that the compiler is really called with -generateJsInteropExports and not just SuperDevMode? 

Also in some rare cases the incremental compile cache of SuperDevMode can cause strange behavior (e.g. make things work that are broken, or the other way around). If you want to be double sure that SuperDevMode works you can start SDM, visit localhost:9876, hit the small "clean" button and then restart SDM. This will cause SDM to start fresh without any caches.

-- 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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: JsInterop & 2.8.0-SNAPSHOT : calling Java Object in Javascript

Same behaviour with -draftCompile, I've also tried optimizationLevel to 0

Le mercredi 30 décembre 2015 00:35:12 UTC+1, Jens a écrit :
I think it does not look too bad. You can compile your app using -mode PRETTY (or DETAILED if you also need package infos) so you can read the final JS output to see what went wrong. The only difference between SuperDevMode and a normal compile is that a normal compile optimizes your code. When you do a normal compile using -draftCompile then its pretty similar to SuperDevMode. When it works this way then you have probably found a bug caused by optimizations.

-- 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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Tuesday, December 29, 2015

Re: GWT Plugin For Eclipse; Ubuntu 64-Bit; XULRunner Issue

All,

        I continued to search and it appears that the GWT Designer functionality doesn't work with GWT 2.6.0 but does work with GWT 2.6.1 but then fails with GWT 2.7.0.  

       Is the GWT 2.7.0 release note: "GWT Designer doesn't work with 2.7 and is no longer supported." accurate?  If so, is there any alternative to allow the continued use of GWT but with some other GUI for layout management?

Thanks,
KGD

On Tuesday, December 29, 2015 at 11:46:51 PM UTC-5, KGD wrote:
Hello,

   I have been developing an app with GWT and have recently moved my development platform to a 64-bit Dell Poweredge running Ubuntu 15.10.  I installed Eclipse Mars. 1 Release (4.51) and downloaded and installed the GWT Plugin and SDK.  When I attempt to open the GWT Designer, I initially received a message stating that I did not have a compatible version of XULRunner installed.  I finally found what was listed as a compatible version at http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/2012/03/2012-03-02-03-32-11-mozilla-1.9.2/xulrunner-1.9.2.28pre.en-US.linux-x86_64.tar.bz2. and installed it.  Now, I no longer get the error message but GWT Designer still does not open.  Rather, it freezes with a dialog box that states 'initializing.'  From the log, it appears that it starts the local http server.  At this point, I am dead in the water.  I don't see anything else in the logs that indicate what the problem is.

  I would greatly appreciate any feedback or direction on resolving this issue.  My code compiles correctly but GWT Designer simply will not load.  

Thanks,

KGD

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

GWT Plugin For Eclipse; Ubuntu 64-Bit; XULRunner Issue

Hello,

   I have been developing an app with GWT and have recently moved my development platform to a 64-bit Dell Poweredge running Ubuntu 15.10.  I installed Eclipse Mars. 1 Release (4.51) and downloaded and installed the GWT Plugin and SDK.  When I attempt to open the GWT Designer, I initially received a message stating that I did not have a compatible version of XULRunner installed.  I finally found what was listed as a compatible version at http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/2012/03/2012-03-02-03-32-11-mozilla-1.9.2/xulrunner-1.9.2.28pre.en-US.linux-x86_64.tar.bz2. and installed it.  Now, I no longer get the error message but GWT Designer still does not open.  Rather, it freezes with a dialog box that states 'initializing.'  From the log, it appears that it starts the local http server.  At this point, I am dead in the water.  I don't see anything else in the logs that indicate what the problem is.

  I would greatly appreciate any feedback or direction on resolving this issue.  My code compiles correctly but GWT Designer simply will not load.  

Thanks,

KGD

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 Compiler Question for Streams

You can still use Guava functional idioms in particular FluentIterable [1] gives you a more java8 feeling

[1] http://google.github.io/guava/releases/snapshot/api/docs/com/google/common/collect/FluentIterable.html

On 29/12/15 15:43, Paul Mazzuca wrote:
It appears that you are correct.  I misread the posts the first time I searched. Thanks for the quick clarification.

On Tue, Dec 29, 2015 at 10:38 AM, Juan Pablo Gardella <gardellajuanpablo@gmail.com> wrote:

On 29 December 2015 at 12:30, Paul Mazzuca <paul.j.mazzuca@gmail.com> wrote:
That reference is for the "latest", which I am assuming is still for 2.7, not 2.8?

On Tue, Dec 29, 2015 at 10:26 AM, Juan Pablo Gardella <gardellajuanpablo@gmail.com> wrote:
stream() method is not mentioned in http://www.gwtproject.org/doc/latest/RefJreEmulation.html#Package_java_util. Maybe this is the reason.

On 29 December 2015 at 12:22, Paul Mazzuca <paul.j.mazzuca@gmail.com> wrote:

Any reason why I would be receiving a compiler error in the code below?


//compiles

this.mybutton.addClickHandler(c -> dosomething());



//does not compile
Arrays.asList("one", "two").stream();


I am using the beta Maven release of GWT 2.8 with jdk 1.8.0_60  and am using super dev mode.  


This is either a compiler bug or a Generator has legitimately stopped creating these types.
[INFO]          Compiling 1 permutation
[INFO]             Compiling permutation 0...
[INFO]             [ERROR] An internal compiler exception occurred
[INFO] com.google.gwt.dev.jjs.InternalCompilerException: Unexpected error during visit.
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.translateException(JVisitor.java:111)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:130)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:118)
[INFO] at com.google.gwt.dev.jjs.ast.JReturnStatement.traverse(JReturnStatement.java:40)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.acceptWithInsertRemove(JVisitor.java:168)
[INFO] at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:92)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:139)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:135)
[INFO] at com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:83)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122)
[INFO] at com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:730)
[INFO] at com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:722)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.acceptWithInsertRemoveImmutable(JVisitor.java:172)
[INFO] at com.google.gwt.dev.jjs.ast.JClassType.traverse(JClassType.java:142)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122)
[INFO] at com.google.gwt.dev.jjs.ast.JProgram.visitModuleTypes(JProgram.java:1288)
[INFO] at com.google.gwt.dev.jjs.ast.JProgram.traverse(JProgram.java:1253)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122)
[INFO] at com.google.gwt.dev.jjs.impl.ControlFlowRecorder.execImpl(ControlFlowRecorder.java:163)
[INFO] at com.google.gwt.dev.jjs.impl.ControlFlowRecorder.exec(ControlFlowRecorder.java:46)
[INFO] at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.maybeRecordReferencesAndControlFlow(JavaToJavaScriptCompiler.java:474)
[INFO] at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.compilePermutation(JavaToJavaScriptCompiler.java:352)
[INFO] at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.compilePermutation(JavaToJavaScriptCompiler.java:272)
[INFO] at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:198)
[INFO] at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:50)
[INFO] at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:74)
[INFO] at java.lang.Thread.run(Thread.java:745)
[INFO] Caused by: java.lang.NullPointerException
[INFO] at com.google.gwt.dev.jjs.ast.JMethod.getJsniSignature(JMethod.java:560)
[INFO] at com.google.gwt.dev.jjs.impl.ControlFlowRecorder.computeName(ControlFlowRecorder.java:50)
[INFO] at com.google.gwt.dev.jjs.impl.ControlFlowRecorder.processMethodCall(ControlFlowRecorder.java:195)
[INFO] at com.google.gwt.dev.jjs.impl.ControlFlowRecorder.visit(ControlFlowRecorder.java:158)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.visit(JVisitor.java:683)
[INFO] at com.google.gwt.dev.jjs.ast.JNewInstance.traverse(JNewInstance.java:73)
[INFO] at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127)
[INFO] ... 32 more

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/FbTLVBfrFmM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscribe@googlegroups.com.

To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/FbTLVBfrFmM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.