Hi,
On Tuesday, April 5, 2016 at 9:38:28 PM UTC+2, TazmanianD wrote:
-- Chrome 49 enabled lots of ES6 features, see: http://v8project.blogspot.de/2016/01/v8-release-49.html
Part of this is the so called sloppy function hosting.
A simple example:
ES5 (old semantics) | ES2015 (new semantics) | |
Code | try { function foo() { foo=function(){}; console.log('hello'); } } catch(e) { } foo(); // overwrites behavior foo(); // no-op | try { function foo() { foo=function(){}; console.log('hello'); } } catch(e) { } foo(); // does not overwrite foo(); |
Output | hello | hello hello |
The problem here is the presence of the try catch block and that semantics have changed here.
We investigated this a few months back and all modern versions of GWT should not be impacted.
So my first recommendation would be to upgrade to GWT 2.8-beta1 and see if the issue still exists for you.
On Tuesday, April 5, 2016 at 9:38:28 PM UTC+2, TazmanianD wrote:
I'm duplicating a comment I made in the Chrome group but I thought I should cross-post it here as well. We're using GWT 2.5.0 and we're suddenly experiencing massive errors as well although fortunately for us, they only seem to be affecting our development env and not production.In our case, what I've discovered is that the static initializers for *some* classes are being executed repeatedly. This is fatal for enums as the enum values are recreated each time and they're supposed to be singletons. The result is that EnumMaps for those enums don't work at all. In debugging the code, I found that when the static initializer function reassigns itself to the null function, this works in the function but when the function returns, the function pointer is reset back to where it was originally pointing. This means that next time the initializer is executed, instead of it being a no-op, it runs again. I almost wonder if there's some sort of scope confusion and the function assignment is assigning to the wrong or duplicate function.And another thing I'll note is that we have soft-permutations enabled in our dev env and when we disable those and generate separate permutations, the problem goes away. I don't see how that can explain what I saw in my debugger but I thought it was worth mentioning.Unfortunately my attempts at reducing the problem to a simple case have totally failed as when I delete too much, the problem seems to disappear. This unfortunately makes my report here not terribly useful but maybe others can chime in if their seeing the same thing.But let me try to summarize with some pseudo-code (a simple example like this does *not* exhibit the problem):class MyEnum {static {Window.alert("Static Initializer");}public void foo() {...}}MyEnum instance = new MyEnum();instance.foo();-- When this code is run the alert "Static Initializer" is displayed twice (or more if you have additional usages)--- Get's compiled into (approximately):var instance = $clinit$MyEnum(), new MyEnum();$clinit$MyEnum(), instance.foo();function $clinit$MyEnum() {$clinit$MyEnum() = nullFunction; // Disables the static initializer so it doesn't run again$wnd.alert("Static Initializer");}-- What I see in the Chrome debugger is that when $clinit$MyEnum is assigned to the nullFunction, the watch immediately reflects this. However the moment you step back out of the function, the value of "$clinit$MyEnum" returns to the original function.
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.
No comments:
Post a Comment