[gwt-contrib] Re: Thinking about a better way to inject JSNI
On Fri, Dec 12, 2008 at 10:57 AM, Scott Blum wrote: > There might be a simpler variant to what you propose but in a similar > spirit. Instead of injecting code into static initializers, could we just > use an ASM visitor to gather the information that we'd get later through > reflection, without actually having to load the target class? That's why I like the inject-in-clinit style, we don't have the complexity of injection from CCL and injection is done only on-demand after the class has been loaded. I think the visitor to gather the data that we want is probably about as complex as the rewriter. javap made it trivial to determine the right instructions to issue. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Thinking about a better way to inject JSNI
There might be a simpler variant to what you propose but in a similar spirit. Instead of injecting code into static initializers, could we just use an ASM visitor to gather the information that we'd get later through reflection, without actually having to load the target class? On Thu, Dec 11, 2008 at 5:12 PM, BobV wrote: > My original solution to the ClassCircularityError was to implement > an ASM visitor that added or modified a class's static initializer to > call over to CCL.injectJsni(). This ensured that the Class was > fully-reified before any attempt at dispId assignment was attempted. > Even though it is mechanically more complicated than performing > injection from within findClass(), it is conceptually easier to reason > about the timing. > > Given that we now require the user to specify all modules to be > loaded on the command-line of hosted mode, it is now feasible to > compute all JSNI code that might be reachable from the entry point. > As long as we're careful not to prematurely trigger class > initialization, we could inject all JSNI in one fell swoop, but at the > cost of injecting more code than we otherwise would into the browser. > > -- > Bob Vawter > Google Web Toolkit Team > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Thinking about a better way to inject JSNI
On Thu, Dec 11, 2008 at 5:12 PM, BobV wrote: > My original solution to the ClassCircularityError was to implement > an ASM visitor that added or modified a class's static initializer to > call over to CCL.injectJsni(). This ensured that the Class was > fully-reified before any attempt at dispId assignment was attempted. > Even though it is mechanically more complicated than performing > injection from within findClass(), it is conceptually easier to reason > about the timing. > I think this also fits well with Instant Hosted Mode, though it seems a large enough chunk of work to perhaps wait for higher-priority tasks. I assume this would work for non-OOPHM hosted mode as well, right? > Given that we now require the user to specify all modules to be > loaded on the command-line of hosted mode, it is now feasible to > compute all JSNI code that might be reachable from the entry point. > As long as we're careful not to prematurely trigger class > initialization, we could inject all JSNI in one fell swoop, but at the > cost of injecting more code than we otherwise would into the browser. > That is only true once we abandon GwtShell, right? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
