Google Web Toolkit: 2015

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

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).

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.)

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.)

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.

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.

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?

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.

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....

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)

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.

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: