The thing is, if B is a subtype of A, and B is rescued, then A is also rescued.
Yeah, the rub is that B did not get rescued into FragmentB, it just ended up there because it was in the set of FragmentA+FragmentB, but not FragmentA or FragmentB individually, in which case it ends up in whichever fragment is last. (This is what the "overwriting preexisting entries" comment in CodeSplitter.updateMap is talking about, although I really didn't understand it the first few times I read it). And, AFAIK, this would not be a big deal for normal static fields, because they're only initialized in clinits, which, in theory, would only be called once both FragmentA+FragmentB were truly loaded, and so the code was indeed live. Class literals are special because they're initialized immediately when the fragment loads (so there isn't a chance for it to wait until the combination of FragmentA+FragmentB is loaded).
but I wonder if we're not missing a deeper bug, I would hate to have a never ending stream of 'fixups' that we have to keep extending. :(
I agree, I was concerned about that as well, and mused about it on the scalagwt list. However, after thinking through the rationale above (class lits being initialized on fragment load), I became fairly convinced that this isn't masking a deeper bug. http://gwt-code-reviews.appspot.com/1513803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
