How to get the full StackTrace when using SuperDevMode in GWT 2.7?

[confile]

I use GWT 2.7 with super dev mode. When it comes to an exception the stack trace looks like the following:

SEVERE: UncaughtExceptioncom.github.nmorel.gwtjackson.client.exception.JsonDeserializationException: Unknown property 'uploadImageId'
    at Unknown.AHc_g$(Unknown Source)
    at Unknown.vHc_g$(Unknown Source)
    at Unknown.OHc_g$(Unknown Source)
    at Unknown.VHc_g$(Unknown Source)
    at Unknown.aIc_g$(Unknown Source)
    at Unknown.gIc_g$(Unknown Source)
    at Unknown.rDc_g$(Unknown Source)
    at Unknown.qDc_g$(Unknown Source)
    at Unknown.vNb_g$(Unknown Source)
    at Unknown.nNb_g$(Unknown Source)
    at Unknown.oNb_g$(Unknown Source)
    at Unknown.pNb_g$(Unknown Source)
    at Unknown.gNb_g$(Unknown Source)
    at Unknown.fNb_g$(Unknown Source)
    at Unknown.$Cc_g$(Unknown Source)
    at Unknown.ZCc_g$(Unknown Source)
    at Unknown.zOm_g$(Unknown Source)
    at Unknown.anonymous(Unknown Source)
    at Unknown.ZDe_g$(Unknown Source)
    at Unknown.aEe_g$(Unknown Source)
    at Unknown.anonymous(Unknown Source)
    at Unknown.anonymous(Unknown Source)
    at Unknown.anonymous(Unknown Source)
    at Unknown.anonymous(Unknown Source)
    at Unknown.anonymous(Unknown Source)
    at Unknown.anonymous(Unknown Source)

How can I get the full stack track deobfuscated with SuperDevMode?

[confile]

I also use the following flag:

-XmethodNameDisplayMode Full 

It does not work. I have a GWT project running in a GWT-PhoneGap environment on my iPhone and I use the Safari Console for Debugging.

[Jens]

I think the current state of client side exception logging is as follows (using GWT 2.8.0-SNAPSHOT):

1) You do not inherit Logging.gwt.xml nor LoggingDisabled.gwt.xml:

     a) You do not install a GWT.setUncaughtExceptionHandler()

          => Exceptions escape to the browser and Chrome console shows them with clickable links on the right side pointing to the source mapped Java file and the correct line number. However, if the java exception has a cause chain you will not see that cause chain at all in the console. That is really annoying because often you just see the stack of some GWT internal code because exception has been caught by GWT (e.g. UmbrellaException) which basically hides the real cause.

     b) You do install a GWT.setUncaughtExceptionHandler() and use GWT.log() or java.util.Logger.log() to print the exception

          => GWT.log(): will print the exception message, followed by the exception cause chain and finally a native exception stack trace. The exception cause chain is a manually build String and logged as String so you can not click anything in that cause chain in the console. Since method names are obfuscated it doesn't help a lot. The only thing you can click is the native stack trace but that contains the stack to the location where you logged the exception and not the stack of the exception itself (usually points to the GWT.log() call in the UncaughtExeptionHandler)

          => Logger.getLogger().log(): Will not print out anything because for some weird reason Logger will always be rebound to LoggerImplNull. This does look like a bug because LogImpl.gwt.xml indicates that Logger should work if superdevmode = on is given. 

2.) You do inherit Logging.gwt.xml

If you do not install a UncaughtExceptionHandler yourself, then GWT will now install one for you which calls Logger to log exceptions. The situation is now similar to 1b) except that the output format looks a bit different. You see the exception message, the cause chain rendered as String (and thus not clickable) and a clickable, native stack trace that usually points to Impl -> Logger -> ConsoleLogHandler which does not give you anything.

So in general the situation kind of sucks right now. What I usually do right now is to tell Chrome to stop on any caught / uncaught exception and then click "continue" in the debugger until Chrome stops at the exception that I need to fix. That way I don't have to search through obfuscated method names.

-- J.

[confile]

Well this still does not solve the problem!

[Jens]

Well this still does not solve the problem!

Yeah thats true and thats why I said that it currently kind of sucks. 

If 1a) would also show the java cause chain then there would be at least one way to get some useable information reliably. 

Currently the best thing is to stop in the debugger. The debugger (at least Chrome and possibly FireFox) evaluates the display name calculated when using -methodNameDisplayMode and usually uses source maps.

IMHO printing/logging stack traces is in most cases useless for now.

-- J.

[Jens]

Well this still does not solve the problem!

As a workaround you can try using: https://gist.github.com/jnehlmeier/cddbc476fd330b1d4999

I use the master branch of GWT but I think it should also work with GWT 2.7. In Chrome I get clickable stack traces that point to the source mapped Java file and it also special cases UmbrellaException which might have more than one cause chain (e.g. you have two listeners on a button and both throw an exception you will see both causes and not just the first one).

-- J.

[Jens]

Forgot to mention: to get clickable, source mapped stack traces you need Chrome 40 beta.

-- J.

[confile]

I am using GWT-PhoneGap with my iPhone 5. This means that I have to use Safari as dev console.

[Ray Cromwell]

You need to get the underlying Javascript exception trace, not the GWT
Exception.getStackTrace(). I guess no one has been testing or
updating StackTraceDeobfuscator on the server. We added code IIRC to
preserve the original underlying JS Error object in GWT, but probably
no one paid attention to hooking up StackTraceDeobfuscator for
browsers that don't support showing nice stack traces (or
deobfuscating logs correctly in SDM)

So the short answer is, you need to turn on GWT logging, and use the
Remote stack trace deobfuscator stuff. That means the -aux output in
the SDM directory needs to be seen by your deobfuscation servlet.

> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-co...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/7d575edb-4ce0-4cf1-831a-82048bab6161%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[confile]

I tested the exception handler (https://gist.github.com/jnehlmeier/cddbc476fd330b1d4999) 

This is what I did: 

    logger.log(Level.SEVERE, "RuntimeException", new RuntimeException("2 + 2 = 5"));

    GWT.log("RuntimeException", new RuntimeException("2 + 2 = 5"));

And my output is still obfuscated:

Mon Dec 08 18:15:18 GMT+100 2014 buddyisLogger

SEVERE: RuntimeExceptionjava.lang.RuntimeException: 2 + 2 = 5

at Unknown.NOc_g$(Unknown Source)

at Unknown.IOc_g$(Unknown Source)

at Unknown._Oc_g$(Unknown Source)

at Unknown.gPc_g$(Unknown Source)

at Unknown.G_g$(Unknown Source)

at Unknown.L_g$(Unknown Source)

at Unknown.a5i_g$(Unknown Source)

at Unknown._4i_g$(Unknown Source)

at Unknown._g_g$(Unknown Source)

at Unknown.xng_g$(Unknown Source)

at Unknown.bog_g$(Unknown Source)

at Unknown.hog_g$(Unknown Source)

at Unknown.y5i_g$(Unknown Source)

at Unknown.R5i_g$(Unknown Source)

at Unknown.Q5i_g$(Unknown Source)

at Unknown.A_g$(Unknown Source)

at Unknown._hk_g$(Unknown Source)

at Unknown.kNe_g$(Unknown Source)

at Unknown.QMe_g$(Unknown Source)

at Unknown.LMe_g$(Unknown Source)

at Unknown.cNe_g$(Unknown Source)

at Unknown.IMe_g$(Unknown Source)

at Unknown.kLe_g$(Unknown Source)

at Unknown.nLe_g$(Unknown Source)

at Unknown.anonymous(Unknown Source)

at Unknown.callback_0_g$(Unknown Source)

java.lang.RuntimeException: 2 + 2 = 5

  at NOc_g$

  at IOc_g$

  at _Oc_g$

  at gPc_g$

  at G_g$

  at L_g$

  at a5i_g$

  at _4i_g$

  at _g_g$

  at xng_g$

  at bog_g$

  at hog_g$

  at y5i_g$

  at R5i_g$

  at Q5i_g$

  at A_g$

  at _hk_g$

  at kNe_g$

  at QMe_g$

  at LMe_g$

  at cNe_g$

  at IMe_g$

  at kLe_g$

  at nLe_g$

  at anonymous

  at callback_0_g$

Am Montag, 8. Dezember 2014 15:45:35 UTC+1 schrieb Jens:

[Jens]

So the short answer is, you need to turn on GWT logging, and use the
Remote stack trace deobfuscator stuff. That means the -aux output in
the SDM directory needs to be seen by your deobfuscation servlet.

Maybe https://code.google.com/p/google-web-toolkit/issues/detail?id=7693 should be fixed in a 2.7.1 or so.

A remote API for CodeServer which is callable via JS is preferred since not everyone uses a Java backend.

-- J.

[Jens]

I tested the exception handler (https://gist.github.com/jnehlmeier/cddbc476fd330b1d4999) 

This is what I did: 

    logger.log(Level.SEVERE, "RuntimeException", new RuntimeException("2 + 2 = 5"));

    GWT.log("RuntimeException", new RuntimeException("2 + 2 = 5"));

The handler is meant to be used with GWT.setUncaughtExceptionHandler(), so for exceptions you have not caught and logged yourself. For testing purpose you can do 

new SuperDevModeUncaughtExceptionHandler().onUncaughtException(new RuntimeException("test"));

-- J. 

[confile]

I use it like this:

GWT.setUncaughtExceptionHandler(new SuperDevModeUncaughtExceptionHandler());

[Jens]

I use it like this:

GWT.setUncaughtExceptionHandler(new SuperDevModeUncaughtExceptionHandler());

Then just throw an exception somewhere in your app that you do not catch yourself. The handler does not fix your java.util.logging.Logger or GWT.log() calls.

But as you are using Safari you might not get any benefit of it anyways. In that case, as already said, your only chance is to use remote logging and use StackTraceDeobfuscator on a server to make the exception readable.

-- J.

[Goktug Gokdogan]

The stack traces that are logged as escaped exceptions (with missing causes) and the ones that are logged by Logger (without inheriting c.g.gwt.logging) will be deobfuscated by Chrome dev tools (if haven't already fixed in Dev channel).

Being said that, I don't understand why you are not seeing pretty names for your methods. Are you not using incremental?

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/e0ebec63-bd88-4f12-b9f3-bbb59fbe4763%40googlegroups.com.

[confile]

I use GWT-PhoneGap on an iPhone5 and Super Dev Mode. SDM works file. I use the Safari console for logging. 

It would be great if you could provide an example of how StackTraceDeobfuscation worked. I see there is a lack in the documentation.

Michael

Am Montag, 8. Dezember 2014 21:28:56 UTC+1 schrieb Goktug Gokdogan:

The stack traces that are logged as escaped exceptions (with missing causes) and the ones that are logged by Logger (without inheriting c.g.gwt.logging) will be deobfuscated by Chrome dev tools (if haven't already fixed in Dev channel).

Being said that, I don't understand why you are not seeing pretty names for your methods. Are you not using incremental?

On Mon, Dec 8, 2014 at 10:25 AM, Jens <jens.ne...@gmail.com> wrote:

I use it like this:

GWT.setUncaughtExceptionHandler(new SuperDevModeUncaughtExceptionHandler());

Then just throw an exception somewhere in your app that you do not catch yourself. The handler does not fix your java.util.logging.Logger or GWT.log() calls.

But as you are using Safari you might not get any benefit of it anyways. In that case, as already said, your only chance is to use remote logging and use StackTraceDeobfuscator on a server to make the exception readable.

-- J.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Jens]

The stack traces that are logged as escaped exceptions (with missing causes) and the ones that are logged by Logger (without inheriting c.g.gwt.logging) will be deobfuscated by Chrome dev tools (if haven't already fixed in Dev channel).

Being said that, I don't understand why you are not seeing pretty names for your methods. Are you not using incremental?

Not sure who you mean since you answered my mail but for me it is pretty clear:

1.) deobfuscation only works in Chrome 40 (currently beta) and only if you do not inherit Logging/LoggingDisabled but still use Logger to log the exception. AFAICT it doesn't work at all using GWT.log() because currently SuperDevModeLogger only builds a plain String of the Java exception for now. 

People might use other browsers, like confile/Michael who develops on his iPhone using Safari. 

2.) There seem to be a bug in LogImpl.gwt.xml because Logger output does not appear in SuperDevMode if you do not inherit Logging.gwt.xml. At least I wasn't able to make it work in a small app of mine (maybe the superdevmode property is always "off" in incremental mode?)

3.) If you inherit Logging to make Logger work you automatically loose deobfuscated stack traces because the Logger is now configured differently.

Can't we streamline it so it always works (at least in Chrome 40) no matter what is inherited and what is not inherited?

-- J.

[Goktug Gokdogan]

On Mon, Dec 8, 2014 at 1:00 PM, confile <michael....@googlemail.com> wrote:

I use GWT-PhoneGap on an iPhone5 and Super Dev Mode. SDM works file. I use the Safari console for logging. 

The problem is you shouldn't be seeing obfuscated method names in GWT 2.7 SDM as incremental compiler uses pretty names. You should see "at Unknown.somethingMeaningfulHere$(Unknown Source)" instead of "at Unknown.gPc_g$(Unknown Source)" without stacktrace deobfuscation.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/6a0c1571-da4a-4ba5-8ff2-77a68c06e517%40googlegroups.com.

[Goktug Gokdogan]

On Mon, Dec 8, 2014 at 1:11 PM, Jens <jens.ne...@gmail.com> wrote:

The stack traces that are logged as escaped exceptions (with missing causes) and the ones that are logged by Logger (without inheriting c.g.gwt.logging) will be deobfuscated by Chrome dev tools (if haven't already fixed in Dev channel).

Being said that, I don't understand why you are not seeing pretty names for your methods. Are you not using incremental?

Not sure who you mean since you answered my mail but for me it is pretty clear:

I was actually responding to confile but your mail happened to be the last one :)

 

1.) deobfuscation only works in Chrome 40 (currently beta) and only if you do not inherit Logging/LoggingDisabled but still use Logger to log the exception. AFAICT it doesn't work at all using GWT.log() because currently SuperDevModeLogger only builds a plain String of the Java exception for now. 

I should fix GWT.log to use new the Logger mechanism. As this was relatively last minute, it is not well polished all around.

 

People might use other browsers, like confile/Michael who develops on his iPhone using Safari. 

2.) There seem to be a bug in LogImpl.gwt.xml because Logger output does not appear in SuperDevMode if you do not inherit Logging.gwt.xml. At least I wasn't able to make it work in a small app of mine (maybe the superdevmode property is always "off" in incremental mode?)

This is interesting. Can you provide me something to reproduce this?

 

3.) If you inherit Logging to make Logger work you automatically loose deobfuscated stack traces because the Logger is now configured differently.

Can't we streamline it so it always works (at least in Chrome 40) no matter what is inherited and what is not inherited?

That is what I wanted but I was hesitant to touch all other places at the very last minute. Could you file a bug and assign it to me? We should improve this by next release.

 

-- J.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/b2c274dc-0c28-4e76-befd-7ee17fd3a26a%40googlegroups.com.

[Jens]

2.) There seem to be a bug in LogImpl.gwt.xml because Logger output does not appear in SuperDevMode if you do not inherit Logging.gwt.xml. At least I wasn't able to make it work in a small app of mine (maybe the superdevmode property is always "off" in incremental mode?)

This is interesting. Can you provide me something to reproduce this?

Just use a new empty project and add a logging statement. See: https://code.google.com/p/google-web-toolkit/issues/detail?id=9045

 

Can't we streamline it so it always works (at least in Chrome 40) no matter what is inherited and what is not inherited?

That is what I wanted but I was hesitant to touch all other places at the very last minute. Could you file a bug and assign it to me? We should improve this by next release.

https://code.google.com/p/google-web-toolkit/issues/detail?id=9046

You have to assign these bugs yourself, as I do not have privileges to assign bugs.

I thought about providing a partly patch for issue 9046. I think a good start is to introduce c.g.g.core.client.impl.ConsoleLogger which is a combination of SuperDevModeLogger and the custom native stack trace logic of LoggerConfiguratorConsole. In addition I would add logic to walk through the cause chain. Then let SuperDevModeLogger and LoggerConfiguratorConsole.SimpleConsoleLogHandler delegate to that ConsoleLogger.

That way Logger and GWT.log() would behave the same way if only LogImpl.gwt.xml is inherited.

-- J.

[Goktug Gokdogan]

Thanks, I'll look into the issues.

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/0b75d6c5-05d4-4b4c-8d69-f3de7b443a33%40googlegroups.com.

[Ray Cromwell]

He said he's not using Chrome, he's using Safari, which I don't think
respects the displayName feature. We can't rely on cross-browser
debugging supporting a client-side Chrome proprietary feature. IDEs
and SDM need to support source-map/symbolmap based log deobfuscation.

>>>> an email to google-web-toolkit-co...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/e0ebec63-bd88-4f12-b9f3-bbb59fbe4763%40googlegroups.com.
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-co...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/6a0c1571-da4a-4ba5-8ff2-77a68c06e517%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-co...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA10f-igQmV3zcSgH71S25AKhCX0GFs0LTVBd%3DOb%2BYjGNw%40mail.gmail.com.

[Goktug Gokdogan]

We are using pretty naming in 2.7 so even using Safari he should get non-obfuscated names by default. If I'm not missing anything; if he is getting obfuscated names either he is using trunk (not 2.7) or incremental is not enabled.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7dUkJxbLxdDpP9wkeBmswqs4DcUob4PrtpOXG2aeuWwsw%40mail.gmail.com.

[Goktug Gokdogan]

BTW, displayName, even though is not standard, is not Chrome proprietary.

Firebug supports it. Supposedly Safari should be supporting it as well: https://bugs.webkit.org/show_bug.cgi?id=25171

If it is not fixed by next release, we should provide at least an opt-out for incremental name obfuscation (which is only enabled on the trunk, not 2.7).

[confile]

I use the latest trunk and also SDM with incremental compile. @Goktug could you please provide a sample project where obfuscation works which has the correct configuration?

Am Dienstag, 9. Dezember 2014 02:11:31 UTC+1 schrieb Goktug Gokdogan:

We are using pretty naming in 2.7 so even using Safari he should get non-obfuscated names by default. If I'm not missing anything; if he is getting obfuscated names either he is using trunk (not 2.7) or incremental is not enabled.

>>>> an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/e0ebec63-bd88-4f12-b9f3-bbb59fbe4763%40googlegroups.com.
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/6a0c1571-da4a-4ba5-8ff2-77a68c06e517%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA10f-igQmV3zcSgH71S25AKhCX0GFs0LTVBd%3DOb%2BYjGNw%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Stephen Haberman]

> I use the latest trunk and also SDM with incremental compile. @Goktug
> could you please provide a sample project where obfuscation works
> which has the correct configuration?

FWIW I'm using a snapshot of GWT master from ~last week, SDM, Chrome
40.0.2214.28, and when I set a breakpoint in FooPresenter.java (which
does pull up via the Control-O shortcut), the call stack is:

en_g$
pn_g$
qn_g$
yJo_g$
....

Oh right.

So, Michael, in 2.7 release, SDM was outputting pretty names. However,
in master (e.g. post-2.7), after commit 676ca7532bd1387, the JS
function names are obfuscated again.

However, per Goktug, the idea is that, in Chrome/FF/and Safari
soon-ish, the browser should use source maps to show the right names.

I'm not entirely sure that's working for me in the Chrome debugger
right now, but it makes sense. (It says "Please wait a bit. source map
is being loaded!" but it's not loading...)

Ah, okay, AFAICT it was because I had the debugger paused in a place
that was fired on page load, so the sourcemaps hadn't had a chance to
load yet, and the breakpoint was blocking that from happening...

Nice. Now it basically works. I see in the call stack, on the right
side, the sourcemapped location of each function (e.g. Ur_g$ is
FooPresenter.java).

Chrome seems to lock up for a bit while loading the sourcemap file. But
looking pretty nice.

Anyway, Michael, Gotkug is saying that if you have a browser like
Safari/Mobile Safari that isn't picking up the sourcemaps to show nicer
function names, you should revert to GWT 2.7 final. Or they may
possibly add a "still use pretty names" override if Safari doesn't get
around to showing the nicer, sourcemapped function names.

- Stephen

[Goktug Gokdogan]

Yes, that's what I mean.

If you use the latest trunk right now, you will see obfuscated method names in Safari. We need to improve that. You need to go back to 2.7 Final.

If you set -XmethodNameDisplayMode flag (e.g. -XmethodNameDisplayMode ONLY_METHOD_NAME) you should also see the nice function names.

 

Chrome seems to lock up for a bit while loading the sourcemap file. But
looking pretty nice.

Anyway, Michael, Gotkug is saying that if you have a browser like
Safari/Mobile Safari that isn't picking up the sourcemaps to show nicer
function names, you should revert to GWT 2.7 final. Or they may
possibly add a "still use pretty names" override if Safari doesn't get
around to showing the nicer, sourcemapped function names.

- Stephen

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/20141209102726.0ab0315f%40sh9.