Smells a bit like JSNI that doesn't cope well with being rewritten then, or some other code depending on a local variable not being renamed. That might give you a good starting point, or else debugging OBF JavaScript, with or without sourcemaps is probably the way to hunt it down.
Fortunatly, you know the series of steps that cause the issue to be replaced, which should allow you to remove large portions of your app. This'll do two main things - limit compile times, and reduce the size of the .cache.html, always a plus when trying to hunt a bug in compiled code. On Thursday, December 13, 2012 5:28:53 PM UTC-6, BDT wrote: > > Thanks for the feedback. > > - I had already given up on using closure compile since it was causing a > bunch of problems in funky CSS things I do. > - I tried optimize level 0 and 9 for each setting. > - Yes, it works with both DETAILED and PRETTY. > > The thing thats baffling me is that this is all code that has worked and > worked with this version of the tools. I must have changed something small > that has blown things up. > > On Thursday, December 13, 2012 11:33:52 AM UTC-8, Colin Alworth wrote: >> >> I've not seen this specific issue (GWT 2.5.0 from Juno or maven command >> line on both mac and linux) in my projects that use RequestFactory, at >> least not from a source where I can point to as our own JSNI mistakes. >> >> One kind of error I've seen that only emerges in OBF is JSNI local >> variable rewriting. In the specific cases I'm referring to, it usually only >> matters when something is relying on that name staying the same, such as an >> eval. Which is not great code to have in a library anyway... >> >> If using 2.5.0 and the optional Closure Compiler optimization, more >> issues like this can arise - Closure is much more aggressive than style=OBF. >> >> One more thing to consider - is your optimization level the same when >> running as both OFB and PRETTY? By default, setting the style to PRETTY >> turns down the optimizations level. I'm having trouble backing up this >> statement with source code, so take it with a grain of salt, but perhaps >> try setting -optimize 9 (see >> https://developers.google.com/web-toolkit/doc/latest/DevGuideCompilingAndDebugging#DevGuideCompilerOptions) >> >> or optimizationLevel set to 9 if using maven (see >> http://mojo.codehaus.org/gwt-maven-plugin/compile-mojo.html#optimizationLevel >> ). >> >> And finally, does it work with DETAILED? The string interning >> optimization is skipped in PRETTY, as to make code more readable, but is >> run when you use DETAILED, as a sort of way to get slightly readable OBF >> code. >> >> If all of these don't work, you may be left with using sourcemaps to >> seewhere in Java code it is failing, or pause on exception in a JS >> debugger, and try to find a variable or stack frame that looks like code >> you know to see where it is happening. >> >> On Thursday, December 13, 2012 3:45:02 AM UTC-6, BDT wrote: >>> >>> Suddenly I am getting all kinds of runtime exceptions when compile >>> obfuscated. If I compile set to pretty, everything is fine. This is not >>> new code and I did not just update my tools. I have tried completely >>> cleaning everything out and rebuilding, reverting to old known good code, >>> etc to no avail. >>> >>> I am using GWT 2.5 + Eclipse Juno on a Mac. I am running on the >>> assumption that I must have changed something in the environment but I >>> don't know what. >>> >>> The most common exception is an UnsupportedOperationException from >>> ValueCode.java:339 when making RequestFactory calls (.fire). >>> >> -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/EfVOOYL_KVsJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
