I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

Dear fellow GWT users,

I would like to announce that I have finally solved what I always thought to be GWT's greatest weakness: its lack of debugging information for client-side exceptions in production.  

With my patch, your deployed app will be able to report stack traces like this:

com.google.gwt.core.client.JavaScriptException: (TypeError) : a is null

com.google.gwt.dom.client.DOMImplMozilla.$getBodyOffsetLeft(DOMImplMozilla.java:145) 

com.google.gwt.user.client.ui.PopupPanel.$setPopupPosition(Document.java:1287)

com.google.gwt.user.client.ui.PopupPanel.setPopupPosition(PopupPanel.java:884)

com.google.gwt.user.client.ui.PopupPanel.PopupPanel(PopupPanel.java:453) 

com.typeracer.commons.client.widgets.EnhancedPopup.EnhancedPopup(EnhancedPopup.java:32)

com.typeracer.commons.client.widgets.PopupWithIcon.PopupWithIcon(PopupWithFocusableTextBox.java:28) 

com.typeracer.main.client.controller.TyperacerUncaughtExceptionHandler$1.execute(TyperacerUncaughtExceptionHandler.java:55) 

com.google.gwt.core.client.impl.SchedulerImpl.runScheduledTasks(SchedulerImpl.java:50) 

etc... :-)

instead of the current state of affairs that looks like this:

lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName:  http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html 

stack: @http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 

Rub@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423 

dSb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190 

tA@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 

Xmb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289 

etc... :-(

I am asking the community to support me in finishing this effort and integrating my patch into GWT.  Please take a look and what I've done, and consider making a donation:

http://igg.me/at/gwt-stack-traces/x/3494291

I am an indie developer and I just need some funding to continue this work.  I'm looking for both grassroots and corporate sponsorship for my quest of improving GWT's error reporting and debugging support.

I've written a detailed white paper ( http://goo.gl/YGsrQ ) that describes how my solution works and why it is necessary.  I welcome your feedback!

Thanks!

Alex

[John A. Tamplin]

On Wed, Jul 17, 2013 at 4:56 PM, Alex Epshteyn <alexander...@gmail.com> wrote:

I would like to announce that I have finally solved what I always thought to be GWT's greatest weakness: its lack of debugging information for client-side exceptions in production.  

With my patch, your deployed app will be able to report stack traces like this:

com.google.gwt.core.client.JavaScriptException: (TypeError) : a is null

com.google.gwt.dom.client.DOMImplMozilla.$getBodyOffsetLeft(DOMImplMozilla.java:145) 

com.google.gwt.user.client.ui.PopupPanel.$setPopupPosition(Document.java:1287)

com.google.gwt.user.client.ui.PopupPanel.setPopupPosition(PopupPanel.java:884)

com.google.gwt.user.client.ui.PopupPanel.PopupPanel(PopupPanel.java:453) 

com.typeracer.commons.client.widgets.EnhancedPopup.EnhancedPopup(EnhancedPopup.java:32)

com.typeracer.commons.client.widgets.PopupWithIcon.PopupWithIcon(PopupWithFocusableTextBox.java:28) 

com.typeracer.main.client.controller.TyperacerUncaughtExceptionHandler$1.execute(TyperacerUncaughtExceptionHandler.java:55) 

com.google.gwt.core.client.impl.SchedulerImpl.runScheduledTasks(SchedulerImpl.java:50) 

etc... :-)

instead of the current state of affairs that looks like this:

lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName:  http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html 

stack: @http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 

Rub@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423 

dSb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190 

tA@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 

Xmb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289 

etc... :-(

So, something like this has been used at least internally for quite a long time -- what exactly did you have to change in StackTraceDeobfuscator?

--
John A. Tamplin

[mark.e...@gmail.com]

I certainly applaud the obvious time, effort, and care that you've put into these improvements, but "45% size and 22-44% execution speed overhead" sounds like a rather painful penalty to pay.  I'm not sure that's going to be worth using in a performance-sensitive application.  Also, how much does this affect compilation time?

Mark Erikson

[Jens]

Do you plan to maintain that code if it is integrated into GWT or will it be a one time contribution and other people have to wrap their head around it again if your solution needs to be adjusted? 

I ask this because GWT will drop support for IE6/7 relatively soon and probably by the end of 2014 drop support for IE8. Also Opera has switched to Blink/V8 which makes the opera permutation obsolete in the near future. So by the end of 2014 (GWT 3.x) Firefox, Safari, Chrome and Opera are likely to support SourceMaps and in case of IE9+ stack trace emulation is probably not needed.

So by the end of next year a bunch of your code can probably be deleted and other code refactored/optimized to fit this situation. Have you thought about that?

-- J.

[Jens]

I certainly applaud the obvious time, effort, and care that you've put into these improvements, but "45% size and 22-44% execution speed overhead" sounds like a rather painful penalty to pay.  I'm not sure that's going to be worth using in a performance-sensitive application.

If you use emulated stack traces (including line numbers) in current GWT your app size will roughly increase by 100%. So 45% is a lot better of what GWT gives you today.

 

 

  Also, how much does this affect compilation time?

This actually shouldn't matter for ordinary compilation. But it would be interesting to hear in case of SuperDevMode + non SourceMaps browser.

-- J.

[mark.e...@gmail.com]

If you use emulated stack traces (including line numbers) in current GWT your app size will roughly increase by 100%. So 45% is a lot better of what GWT gives you today.

...

Really.  I had not seen that mentioned anywhere.  What sort of approach does the current emulated stack implementation use, as opposed to the suggested function enter/exit approach?  Is there a relative speed hit involved with it too?  Because if so, bring on the new implementation ASAP :)
 

[Alex Epshteyn]

Thanks for all your questions.  Here are my answers.

So, something like this has been used at least internally for quite a long time -- what exactly did you have to change in StackTraceDeobfuscator?

 

Quite a few things, actually.  I go into great detail about that, including diffs of some stack traces, in my paper: http://goo.gl/YGsrQ  In short, my solution is prettier, more efficient, and more accurate than what you've been using.

I'm not sure that's going to be worth using in a performance-sensitive application.  Also, how much does this affect compilation time?

Performance was critical to my application as well, and that's why I put in a lot of extra effort to make my solution almost 50% more efficient than my predecessor's work.  I'm already using it in production on typeracer.com.  You can visit my site and see that it's very fast.

The impact on compilation time is negligible (less than 1 second per permutation).

Do you plan to maintain that code if it is integrated into GWT or will it be a one time contribution and other people have to wrap their head around it again if your solution needs to be adjusted? 

Yes, I will maintain the code regardless, even if it doesn't get integrated into GWT, because my app is already using it in production, and I consider it of high importance to my business.  If my project gets funded, then I will work on integrating it into GWT and maintaining that code thereafter.  Otherwise, if there's not enough interest from the community, I'm not sure I'll bother integrating it.  Either way, my work is pretty self-contained and only touches a handful of existing classes: JsStackEmulator, StackTraceDeobfuscator, and StackTraceCreator.

 

I ask this because GWT will drop support for IE6/7 relatively soon and probably by the end of 2014 drop support for IE8. Also Opera has switched to Blink/V8 which makes the opera permutation obsolete in the near future. So by the end of 2014 (GWT 3.x) Firefox, Safari, Chrome and Opera are likely to support SourceMaps and in case of IE9+ stack trace emulation is probably not needed.

In addition to fixing and optimizing stack emulation, my code makes lots of improvements to the SourceMaps-based approach as well.  That said, right now, only one browser supports SourceMaps-based stack traces.  Let me be clear: my project is not about just any one solution, like stack emulation or SourceMaps: it's to make perfect Java stack traces available in any browser that can run your GWT app.  My code lays the foundation to make that happen with minimal future effort, even as browsers evolve.

 

So by the end of next year a bunch of your code can probably be deleted and other code refactored/optimized to fit this situation. Have you thought about that?

I don't think any of my code will have to be deleted.  I've introduced a selection property that selects whether the browser supports the SourceMaps-based stack traces or not, and introduces stack emulation only if needed.  Otherwise, it uses the SourceMaps-optimized solution, which carries no overhead.

What sort of approach does the current emulated stack implementation use, as opposed to the suggested function enter/exit approach?  Is there a relative speed hit involved with it too?  

My approach to stack emulation is the same as before, just more accurate and more optimized.  The cool thing is that in Chrome and any future browsers which provide both line and column numbers in Javascript stack traces, my code will give you perfect equivalent Java stack traces with absolutely no performance penalty (you can read about how it works in my paper: http://goo.gl/YGsrQ )

Because if so, bring on the new implementation ASAP :)

I'm hoping to!   Please consider making a donation and spread the word about my campaign: http://igg.me/at/gwt-stack-traces/x/3494291 :)

Thanks guys.  Any other questions?   (I'm really excited to be having this discussion with all of you, after working on it in isolation for so long).

- Alex Epshteyn

[RyanZA]

Jens, even with source maps in Chrome, I've been unable to get stack traces to work. They still print out poorly in production when an exception is hit - the exceptions ignore the source maps entirely. I asked previously if there is a way around it, but apparently it's a known issue - so I don't think SourceMaps solve this problem yet.

That said, the size and speed overhead here is terrible and most people would avoid something that adds that much overhead in production (although it would be great in development).

What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads.

I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution.

[Thomas Broyer]

On Thursday, July 18, 2013 3:21:59 PM UTC+2, RyanZA wrote:

Jens, even with source maps in Chrome, I've been unable to get stack traces to work. They still print out poorly in production when an exception is hit - the exceptions ignore the source maps entirely. I asked previously if there is a way around it, but apparently it's a known issue - so I don't think SourceMaps solve this problem yet.

That said, the size and speed overhead here is terrible and most people would avoid something that adds that much overhead in production (although it would be great in development).

What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads.

I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution.

This is what the StackTraceDeobfuscator does already. It's currently based on symbolMaps (GWT-specific) rather than source maps though.

[Ryan Chazen]

Hi Thomas,

It would be great if you (or anybody who understands how to set it up) could add a small article on gwtproject.org about setting up the different methods of getting stack traces in production on exceptions?

Thanks!

Ryan

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/1qDVlPGryKo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Thomas Broyer]

That article was the third result in a Google search for "gwt web mode exceptions": http://www.summa-tech.com/blog/2012/06/11/7-tips-for-exception-handling-in-gwt/

I agree that http://www.gwtproject.org/doc/latest/DevGuideLogging.html#Remote_Logging needs to be expanded.

On Thursday, July 18, 2013 3:38:15 PM UTC+2, RyanZA wrote:

Hi Thomas,

It would be great if you (or anybody who understands how to set it up) could add a small article on gwtproject.org about setting up the different methods of getting stack traces in production on exceptions?

Thanks!

Ryan

On Thu, Jul 18, 2013 at 3:30 PM, Thomas Broyer <t.br...@gmail.com> wrote:

On Thursday, July 18, 2013 3:21:59 PM UTC+2, RyanZA wrote:

Jens, even with source maps in Chrome, I've been unable to get stack traces to work. They still print out poorly in production when an exception is hit - the exceptions ignore the source maps entirely. I asked previously if there is a way around it, but apparently it's a known issue - so I don't think SourceMaps solve this problem yet.

That said, the size and speed overhead here is terrible and most people would avoid something that adds that much overhead in production (although it would be great in development).

What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads.

I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution.

This is what the StackTraceDeobfuscator does already. It's currently based on symbolMaps (GWT-specific) rather than source maps though.

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/1qDVlPGryKo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsub...@googlegroups.com.

[Jens]

What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads.

I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution.

We also do not use emulated stack traces because of performance and code size overhead. So we simply deploy the symbol maps generated by GWT compiler and use StackTraceDeobfuscator on the server. We also extended StackTraceDeobfuscator a bit because we received exceptions where the stack trace is actually inside the exception message instead of the exception stack trace (the exception stack trace was empty). So we try to deobfuscate the exception message as well in this case.

Given the above the quality of stack traces now depends on the browser version our clients use. We do not support IE6/7 and IE 8 support will be dropped next year (regardless of what GWT does). So we mainly deal with newer browsers and we pretty much always get deobfuscated stack traces that provide some useful information. Its not perfect but it works. We never get the concrete line number where the exception occurs but we often enough have the method name. Of course sometimes we have no stack information at all (IE8).

In addition you can enhance the stack trace by providing additional client information. For example you could send the current URL to the server which tells your the current place state if you use GWT Places. You could also implement a custom Logging Handler that logs into a ring buffer and once a client exception occurs you send the last x client log entries along with the stack trace. Or if you do not want to enable logging itself in production you could still use the ring buffer approach and store "user actions" in it and then send these to the server (similar to client side logging). Or you trace user click coordinates and their underlying elements (event preview handler)

So before enabling full stack trace emulation in GWT you can do quite a few things to get information about what has happened inside the app once the exception had occurred. 

Btw. we stopped using SourceMaps for Chrome because for whatever reasons StackTraceDeobfuscator has imports from gwt-dev.jar that are needed when SourceMaps are enabled.

-- J.

 

[Scott Blum]

Very cool.  Bob Vawter and I (and I think a couple more people) worked on this a long time ago, and there's definitely a lot of room for improvement.  Nice to see someone tackle this!

On Wednesday, July 17, 2013 4:56:40 PM UTC-4, Alex Epshteyn wrote:

[Alex Epshteyn]

In response to some of the concerns expressed in this thread, I'd like to clarify that by using my patch, you will not be making any trade-offs versus what you previously had with GWT's old implementation: my patch will give you all "pros" and no "cons."

Here's why:

There are two ways to get perfect stack traces in production: 1) via a compiler-generated source map file in a browser that provides JS stack traces with column numbers (only Chrome right now) and 2) via stack emulation for all other browsers.  My project implements both solutions, along with lots of improvements to their existing implementations in GWT.  So if anyone is already using any of the following: stack emulation, symbol maps, source maps, StackTraceDeobfuscator, etc., my patch will make those things better for you without requiring you to use other pieces that you don't need.  For example, you could configure it to only use solution #1: which gives you perfect stack traces for Chrome and doesn't increase the size of your code.  Or you could additionally enable solution #2, which will cover all the other browsers, with only 45% overhead in code size for those other browsers.  Personally, I think that 45% is totally worth it (especially compared to the 100% overhead incurred in the original solution), and I'm using it in my app, but if you don't want any overhead, you can just take the freebie for Chrome and leave the rest as before.

By the way, who wants to try it?  Please get it touch with me (alex at typeracer.com), and I will email you my patch so you can see for yourself how awesome it is.

[Alfredo Quiroga-Villamil]

I just finished reading the paper presented at:

http://www.indiegogo.com/projects/enable-gwt-to-preserve-java-debugging-info-in-production

depicting some of the areas/improvements he has made to what I personally consider a vital area and a great addition to gwt-core namely logging and proper mapping to java sources in production.

Looking at the donations made so far and obviously at first glance it doesn't look like this work has the significance to many that one might expect. I really feel like the amount of work, complexity of the issue at hand and the overall contribution of the work made by +Alex Epsthteyn is important enough so that we shouldn't let it go unnoticed. By unnoticed I mean how do we find a way to work with him so that his changes are ported and integrated into gwt core.

Are there any plans or conversations regarding this topic among the core GWT developers? Any way to bring, help Alex so he can incorporate/merge a lot of the changes he has made so everyone benefits from it?

I apologize before hand if there are conversations about this somewhere else and I have missed them.

Alfredo

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

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

--
Alfredo Quiroga-Villamil

AOL/Yahoo/Gmail/MSN IM:  lawwton

[Barop, Johannes]

Hi,

2013/7/23 Alfredo Quiroga-Villamil <law...@gmail.com>

Looking at the donations made so far and obviously at first glance it doesn't look like this work has the significance to many that one might expect. I really feel like the amount of work, complexity of the issue at hand and the overall contribution of the work made by +Alex

I have no problem donating money for real OpenSource efforts. As Stephen noticed: Alex does it wrong. I have the impression that he only want's to sell his consulting services. Besides that other individuals here did much greater work and would deserve the money.

--
Johannes Barop - Software Development & Consulting
Alsterdorfer Straße 573
DE-22335 Hamburg

E-Mail: j...@barop.de
Phone.: +49 40 807 907 37
Fax : +49 40 807 907 39
Mobile: +49 176 491 551 38

Web: http://www.barop.de

[Alex Epshteyn]

Alfredo: thanks for your $25 contribution!  I've just emailed you my patch along with a small demo project.

Would be great if we could get more people to pitch in with some funding.  Any corporate takers?

Johannes: IndieGoGo asked me to come up with "perks" to offer to people who contribute money to the campaign.  I set up a $25 "perk" that offers my patch, and the only thing additional commodity I could offer for bigger contributions is my time.  I'm not a consultant and I'm not looking to sell any services beyond getting this patched finished up and integrated into GWT.

[Alex Epshteyn]

Hello folks,

I just wanted to remind everyone that the last day to fund this project is this Friday, August 23.

I've been using this framework in production in my app now for 2 months, and it works great.  Have logged 70,000 perfect stack traces so far!  Already fixed 3 major bugs in my GWT-based UI code that I would NEVER found otherwise.

Let's get this capability into GWT by the end of the year.  Please donate!

Thanks,

Alex

On Wednesday, July 17, 2013 4:56:40 PM UTC-4, Alex Epshteyn wrote:

[Brian Slesinsky]

Thanks for looking into how to improve Java stack traces. I agree that we could do a better job. However, there are some problems with your approach:

First of all, we can't guarantee that we will accept this change. That doesn't seem very fair to whoever might be donating money.

I would like to make sure we come up with a solution taking the best features of everyone's ideas, while remaining as simple as possible. See the discussion about GWT.create() improvements for an example. So the final result will likely be modified and include ideas from multiple contributors, though course the person who volunteers to do most of the work often has the largest influence. And simple patches aren't a solo effort because someone has to review them and try them out.

With a project as complex and widely used as GWT, the drawbacks to a change may be unexpected. It's unfortunate, but we often find that after committing a change to Google's codebase, we discover problems that nobody thought of in review and we not caught by GWT's own tests. It's much easier to test a change if it's broken up into smaller patches.

So if possible it's best to split up a larger feature into smaller patches and consider each of them on their merits. For example, if some things are just bug fixes, we should review and commit them separately. This is often a good way to get started in the community - before trying something large, fix simpler bugs. This gives us a chance to get to know your work through smaller and less risky changes, and you'll likely learn things along the way. Resist the urge to add more features since that makes a change riskier and harder to get agreement on.

- Brian

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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.

[Alex Epshteyn]

Hi Colin, please find my answers inline:

On Tue, Aug 20, 2013 at 11:35 PM, Colin Alworth <nilo...@gmail.com> wrote:

I got a tweet from you asking for a donation (or rather a 'partner', which apparently means 'money'), but couldn't frame a useful response in 140 chars, so since this thread is coming back, I thought to do so here instead.

Yes, I wanted to see if Sencha would be interested in funding this project.  I agree, 140 chars is not enough :)  Just couldn't find your contact info other than Twitter. 

What license are you offering these code samples under - if it isn't something open and available, what is the benefit to an advance copy of the jar if I, an author of a library and several open source tools and applications, cannot provide it to my customers or other downstream users?

That's a good point which I hadn't considered.  I'd be willing to immediately release the code under the same license as GWT if the project gets funded.  

(For anyone who's just joining this thread now, here's the link to my project on IndieGoGo: http://igg.me/at/gwt-stack-traces/x/3494291)

 

We've found that https://gist.github.com/niloc132/3906501 goes a heck of a long ways toward offering optional debug info - if not enabled, the user gets the normal-size application with zero size or performance hit, and by redirecting to a slightly different url, the full trace info can be pulled out (with the quirks you mention of course*), which typically goes a long ways toward identifying the real issue.

Yes, and you'd still be able to use that same config with my patch, except the debug permutation will be much smaller, cleaner, and more accurate.  In fact, the overhead is so insignificant now, that I have that debug configuration enabled for all users on my site (typeracer.com).

* How often have you needed to know which line of Impl.java or DOMImpl.java a stack trace intersects? To make your case more effectively, you might consider using code where it is meaningful to see those lines, something other than the equivelent of java.lang.reflect.Method.invoke(Method.java:601). Perhaps some real life JSNI, or an annoying IE6-9 focus() or setAttribute issue?

Certainly.  At the time of writing I only had a few artificial examples available.  But now that I've been gathering real data from my users in production for a month, I will add an appendix with much better real-world examples.  I'll update this thread when I finish doing that (most likely tomorrow).

 

You touch briefly on the risk of '[exposing] your application’s implementation details', but unless I am mistaken, the extra metadata included in the file:line ints should still be enough to take apart an app and map it to discrete files and reconstruct methods, even un-inlining (as you mention) to pull out clearer details. My understanding was that the premise of the sourceMap was to work entirely from the stack to allow the actual source to be obfuscated, and avoid any other metadata from being left in the compiled output. Combine this with the fact that many of those classes are publicly available (GWT itself, etc), and it seems that you could reverse out a significant portion of the app - the "secret sauce". Can you comment on using this for public applications and any reverse engineering attempts you've made?

Let me first just clarify how my implementation obfuscates file names (I think you understood it correctly, but I just want to be sure).  So in my implementation of stack emulation, the filenames are obfuscated, so you have strings like '23:234'. The decoding table for this "cipher" is not published (it's written as a new file in the same directory as the symbolMap).  So the only thing that you can reconstruct is that the obfuscated JavaScript expression X is on line '234' of file '23'.  I understand that you can use this info to separate the JS output into discrete files, but I'm just not overly concerned with that, because I don't think it's that much more helpful to have many obfuscated files with prettier whitespacing instead of just one lump file.  If necessary, I suppose you could modify the compiler to add some additional obfuscating "salt" to the output.

Thanks for your questions!

Alex

[Alex Epshteyn]

This project is now on GitHub: https://github.com/aepshteyn/gwt-stack-trace-kit

You can download the stack-trace-enabled GWT 2.5.0 SDK from the project releases.

If anyone would like to continue this effort and port this over to the latest GWT branch, I'll do my best to help!

[Lars]

Thanks for sharing this... what is the license of it and is there a patch file (containing only the differences to the GWT SDK) or only the modified classes?

[Alex Epshteyn]

The license is Apache 2.0 (same as GWT).  There's no patch file. I guess you could probably diff it against the GWT source tree yourself.