Does the GWT "magic" ever fail you?

[David Vree]

My company has taken the decision to move from Flex to HTML5/
Javascript for a corporate web-app. So far we are very impressed with
GWT and are thinking of utilizing it, especially since we are mostly a
Java house.

My biggest concern, however, is the wonderful magic that is the GWT
Javascript compiler. If this thing produces production code that is
different from the development code, or if the Javascript isn't
aligned with the Java, I fear we will be unable to effectively
diagnose/debug the problem.

Has this been a problem for folks? Is there some other concern we
should be aware of?

[Samyem Tuladhar]

Well there are some cases where the "development" code is not the same as the executed Javascript code. You'd typically notice this around async RPC calls where the order of events during Java based debugging session is different from the Javascript. But then again this is something you'd have to design around and always be mindful of async operations. Just because it seems to work in development mode does not necessarily ensure it'll behave the same with javascript, but if you know how to properly deal with non-sequential operations, yoiu should be okay. 

[KD]

In my experience, debugging has been OK as long as you are savvy with dev mode. We also have our own exceptions and use GWT logger extensively.

[Jeff Chimene]

On 11/11/2011 12:39 PM, David Vree wrote:
> My company has taken the decision to move from Flex to HTML5/
> Javascript for a corporate web-app. So far we are very impressed with
> GWT and are thinking of utilizing it, especially since we are mostly a
> Java house.
>
> My biggest concern, however, is the wonderful magic that is the GWT
> Javascript compiler. If this thing produces production code that is
> different from the development code, or if the Javascript isn't
> aligned with the Java, I fear we will be unable to effectively
> diagnose/debug the problem.

Not to belittle your observation, but replace "Javascript" with "object
code" and "Java" with "C".

It's a good question - how much do you trust your compiler? As a
profession, we've apparently dealt with this issue in the past:

One thing we do is to disable optimizations. GWT has a compiler mode for
that. However, it produces more code, and one aspect of GWT is to reduce
code bloat. Most real-world compilers have similar a trade-off.

Another thing we do is instrument our code. For example, GWT supports
the java.util.logger framework.

We also employ test-driven development. There is the GWTTest environment
as well as other, superb test frameworks.

> Has this been a problem for folks? Is there some other concern we
> should be aware of?

I'd suggest, if your group hasn't done so, that you create a
proof-of-concept, deploy it to a select group of blind men, and ask them
to describe the resulting Elephant.

Bueno Suerte,
jec

[Thomas Broyer]

Most of the time, you'll be debugging in DevMode, against your Java code, within your Java IDE, using any Java debugger.

GWT 2.5 will generate SourceMaps so you can see your Java code in your browser's dev tools, set breakpoints in the Java code to pause the JS engine, etc. See https://plus.google.com/110412141990454266397/posts/iqXo5AyHkyd and http://www.2ality.com/2011/07/firefox-sourcemap.html

In the mean time, or in browsers where SourceMaps aren't supported, GWT generates symbolMaps that allow you to find where an obfuscated function name comes from in your Java code. It can also be used to automatically deobfuscate stack traces (so you can, for instance, send a client-side exception to the server for logging –using java.util.logging and the SimpleRemoteLogHandler or RequestFactoryLogHandler–, and have the stacktrace automatically deobfuscated in your logs). You can also use the StackTraceDeobfuscator "manually" on the server-side; or look-up in the symbolMaps by yourself (I regularly do it when I can't reproduce a bug in DevMode).

It's important to note that symbolMaps only map methods, whereas SourceMaps map down to the expression level.

So no, it's not a problem.

Also, if your application is "big enough", even if you use "plain JavaScript" instead of GWT, you'll want to use a "JS compiler" (such as the Closure Compiler) or "JS minifier"; so you'll have the same "issues". The Closure Compiler generates SourceMaps, but I don't think any compiler but GWT produces the equivalent of the symbolMaps and have the equivalent of the StackTraceDeobfuscator.

[David Vree]

@Samyem -- Good point about the async RPC...we also had that issue
when debugging and/or integration testing Flex/Actionscript.

@Jeff -- Your metaphore is correct...to continue it, I'd say I trust
my Java/C++/C# compilers a lot. My concern is exactly whether or not
the GWT compiler has issues. Do you disable optimizations during
development or is that for production code too?

@Thomas - Sourcemap is incredible if it works as advertised....is
that how Eclipse keeps the Java debugger "in sync" with the browser
Javascript execution?

Thanks everyone for your answers.

Dave

On Nov 12, 4:52 am, Thomas Broyer <t.bro...@gmail.com> wrote:
> Most of the time, you'll be debugging in DevMode, against your Java code,
> within your Java IDE, using any Java debugger.
>
> GWT 2.5 will generate SourceMaps so you can see your Java code in your
> browser's dev tools, set breakpoints in the Java code to pause the JS
> engine, etc.

> Seehttps://plus.google.com/110412141990454266397/posts/iqXo5AyHkydandhttp://www.2ality.com/2011/07/firefox-sourcemap.html

[Thomas Broyer]

On Saturday, November 12, 2011 6:17:59 PM UTC+1, David Vree wrote:

@Samyem -- Good point about the async RPC...we also had that issue
when debugging and/or integration testing Flex/Actionscript.

@Jeff -- Your metaphore is correct...to continue it, I'd say I trust
my Java/C++/C# compilers a lot.  My concern is exactly whether or not
the GWT compiler has issues.  Do you disable optimizations during
development or is that for production code too?

Last year, they reworked the compiler internals to make it possible to optimize the output even more. That introduced a few bugs, but they were quickly patched (hey, Google relies heavily on GWT, and they all run "from trunk", so any bug they introduce hit them right away, and thus has to be fixed quickly.

That's not much different than the compiler bug in Java 7, fixed a few weeks later in 7.0.1.

@Thomas - Sourcemap  is incredible if it works as advertised....is
that how Eclipse keeps the Java debugger "in sync" with the browser
Javascript execution?

Not at all. When you run in DevMode, you really run your Java code. The plugin you install in your browser calls your DevMode "code server" whenever it needs to reach your code; and when you use JSNI in your code, it's sent to the browser to be evaluated there. Debugging in Eclipse is then really just debugging Java code, connecting to the DevMode "code server" with no more than a "basic" Java debugger.

See http://code.google.com/webtoolkit/doc/latest/DevGuideCompilingAndDebugging.html#DevGuideDevMode and http://code.google.com/p/google-web-toolkit/wiki/DesignOOPHM for details.

AFAICT, the DevMode plugin you install in your browser might at some time be deprecated in favor of on-the-fly generation of SourceMaps and non-optimized JavaScript. But that's in really early stages (see the comments on https://plus.google.com/110412141990454266397/posts/iqXo5AyHkyd, search for "super draft mode")

[Jeff Chimene]

On 11/12/2011 10:17 AM, David Vree wrote:
> @Samyem -- Good point about the async RPC...we also had that issue
> when debugging and/or integration testing Flex/Actionscript.
>
> @Jeff -- Your metaphore is correct...to continue it, I'd say I trust
> my Java/C++/C# compilers a lot. My concern is exactly whether or not
> the GWT compiler has issues. Do you disable optimizations during
> development or is that for production code too?

I want as little code sent to the client on startup as possible, so I
only disable when there's a problem. Actually, I do not disable
optimization, I recompile with the -STYLE DETAILED argument. This
provides enough detail to work through the behavior with FireBug or
whatever IE provides.

My experience is that I inevitably get bit when I don't test on at least
three different browsers. I usually use the set (Safari, IE, FF). Also,
I don't support IE 6, which decision might not be an option for you.

This technique is separate from the -OPTIMZE, -EA, and -DRAFTCOMPILE
arguments. I haven't seen any issues with optimization.

> @Thomas - Sourcemap is incredible if it works as advertised....is
> that how Eclipse keeps the Java debugger "in sync" with the browser
> Javascript execution?
>
> Thanks everyone for your answers.

Thanks for continuing the conversation,
jec

>
> Dave
>
>
>
> On Nov 12, 4:52 am, Thomas Broyer <t.bro...@gmail.com> wrote:
>> Most of the time, you'll be debugging in DevMode, against your Java code,
>> within your Java IDE, using any Java debugger.
>>
>> GWT 2.5 will generate SourceMaps so you can see your Java code in your
>> browser's dev tools, set breakpoints in the Java code to pause the JS
>> engine, etc.
>> Seehttps://plus.google.com/110412141990454266397/posts/iqXo5AyHkydandhttp://www.2ality.com/2011/07/firefox-sourcemap.html
>>
>> In the mean time, or in browsers where SourceMaps aren't supported, GWT
>> generates symbolMaps that allow you to find where an obfuscated function
>> name comes from in your Java code. It can also be used to automatically
>> deobfuscate stack traces (so you can, for instance, send a client-side

>> exception to the server for logging �using java.util.logging and the
>> SimpleRemoteLogHandler or RequestFactoryLogHandler�, and have the

[David Vree]

On Nov 12, 12:36 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
> On Saturday, November 12, 2011 6:17:59 PM UTC+1, David Vree wrote:
>
> Last year, they reworked the compiler internals to make it possible to
> optimize the output even more. That introduced a few bugs, but they were
> quickly patched (hey, Google relies heavily on GWT, and they all run "from
> trunk", so any bug they introduce hit them right away, and thus has to be
> fixed quickly.

The fact that Google is eating their own dog food with GWT is probably
one of the most important considerations. Bugs happen, but their
motivation to address them quickly seems very high. Thats good enough
for me.