A sort of philosophical meta-point that may or may not be of interest... When we started GWT, we were worried about managing the complexity of compile-time code generation, so we tried to find the simplest, most easy-to-debug approach we could think of. GWT's model of never changing existing code[1], but only adding new Java source during the compile, is really a design choice, not a technical limitation. The benefit of the current design is that you can add -gen to hosted mode and map the corresponding folder into your source path, and then easily step through all your code, both handwritten and generated, in the debugger. This avoids tricky or confusing situations wherein the source code you see appears to be doing something different than the bytecode that's running. It seems good to avoid that kind of dichotomy, on the principle that straightforward-though-verbose is generally better than fancy-but-confusing.
[1] Overlay types were the first time we ever even did bytecode rewriting, and that support is implemented at a very deep level. Also, JSOs are intended to be among only a very few "magic" things in GWT (basically, JSNI, GWT.create(), GWT.runAsync(), and JSOs). We went to a lot of effort to ensure that JSOs worked according to a fixed set of rules that are not hard to comply with, even if people don't fully understand why the implementation requires it. On Mon, Apr 20, 2009 at 11:11 AM, Thomas Broyer <[email protected]> wrote: > > > > On 20 avr, 08:43, nicolas de loof <[email protected]> wrote: > > > > I wonder if there is any way to also "pre-process" Java sources, for > > > example > > > > this would enable support for Aspect Oriented Programming or maybe > some > > > > DataBinding framework. > > > > > Depends what you mean by "pre-process"... Generally, generators > > > analyze the class they're called for (for example, looking for > > > specific annotations on methods or on the class itself) and according > > > to this generate a Java class extending the one they've been called > > > for. > > > (is this understandable? is this at least no-so-bad english?) > > > > In many case the generator will create from MyClassX some MyClassXImpl or > > equivalent that extends the original one, bu not REPLACE it as Java > source. > > This is what I mean by "pre-process". > > > > For example, to implement a AOP framework I'd like to instrument all > calls > > to some method. For this reason I'd like a generator / pre-processor to > > check the source files and detect the matching pointcuts to add some > adived > > code. Many other example can apply, including annotation processing for > > declarative coding (ex : @Property annotation to automagically introduce > the > > required PropertyChangeListeners) > > You would generate a subclass that delegates to super.method() after/ > before the aspect(s) code. > > > I never tried it myself, but I'n not sure a generator can REPLACE the > > original Java Source. > > AFAICT, it can't, but there's probably no need for this. > > > I may be wrong but I also thing the generated code is > > only available when using GWT.create(), > > The generator is only called at the point where GWT.create() is called > (I may be wrong but you could generate a different output for each > GWT.create() call-point for the same class literal), so yes, you're > right. > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
