Gotcha. It'd be good to record this in a comment for posterity. On Wed, Apr 22, 2009 at 11:08 AM, John Tamplin <[email protected]> wrote:
> On Wed, Apr 22, 2009 at 10:50 AM, Scott Blum <[email protected]> wrote: > >> On Tue, Apr 21, 2009 at 8:01 PM, <[email protected]> wrote: >> >>> Don't read stack frames from the input, since they aren't required and >>> are >>> incorrect after rewriting >> >> >> Stack frames are incorrect after rewriting? What's the deal with that? >> > > Sorry, it should have been stack maps, not frames, which are used by the > 1.6 verifier if present so it doesn't have to build up maps of what is on > the stack at each bytecode offset. > > I was getting errors trying to analyze a rewritten class while trying to > track down the IncompatibleClassChangeError in IHM, and javap would throw an > exception trying to read beyond the end of the file while ASM would get an > IndexOutOfBoundsException trying to parse the included frame data. Our > rewriters do nothing to handle changing the stack maps as the code is > changed, so they can be incorrect. > > After talking with Toby, the stack maps are optional, and doing the work at > runtime to calculate them is almost certainly slower than just letting the > old verifier compute them. If we were to allow our bytecode rewriting to > take place outside of hosted mode startup, such as a separate build step, > then it might make sense to recompute them. Until then, it is easier to > just drop them. > > -- > John A. Tamplin > Software Engineer (GWT), Google > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
