> > >> There is not much more that what is already discussed earlier in the list > . APT takes responsibility of codegen out of GWT compiler and get more > inline with the rest of the java world and works on GWT/Android/server. > That is basically "what would you do if there was no TypeOracle nor > GWT.create". I think one could actually start experimenting with it today. > >
I have used APT in places, and to be honest, I've found javax.lang.model to be very clunky in comparison to Gwt Ast; the apis are very generic; for example, Element returns .getEnclosedElements(), which itself returns all enclosed Fields, Methods, Constructors and inner Types. That said, one would imagine it to be possible to duplicate a lot of the utility provided in Gwt ast by creating a more verbose, specific api to wrap javax models. Apt does include utilities like javax.lang.model.util.Elements and javax.lang.model.util.Types, which could be encapsulated to perform such functionality as finding subtypes. Of course, the classpath for these utilities are unbounded, so gwt.xml inclusion/exclusion will essentially be ignored. Of course, there is also the matter of gwt.xml properties as well, which I'm sure you guys have all considered as well. > I actually already warned about this earlier. For any GWT.create proposal, > we should put into account moving into APT. That being said I think it is > still valuable for GWT to support some kind of magic-method replacement > mechanism. > Well, in order to implement any kind of magic-method replacement, we'll need a means to visit method bodies; at least to the extent of visiting method bodies. But, without an actual Ast nodegraph, it will be quite difficult to trace down literal values; javax.lang.model.element.VariableElement does provide the means to lookup compile-time constants, but any sort of inlining to reduce to what "should be a compile time constant" would certainly fail (I currently do look up the node graph a little, but that's mostly for developer ease). So, I guess, in terms of a viable path forward, would it be reasonable to say that either writing or finding an extension of APT capable of providing a more usable API would be one worthwhile endeavor? For the matter of magic-method replacement, it will definitely be approximately impossible to do without something like JDT/Lombok to at least handle lexing and rewriting specific method invocations with different source . I would be correct to assume that we're not planning to actually work off compiled bytecode, correct? Is there anything on the table other than JDT, Java 8 compiler plugins or Lombok? Can we depend on jjs ast + GWT.create being relatively stable and exposed for the foreseeable future? Sorry to bombard you all with questions; I know there are no(t many) definitive answers at this time, but it would be nice to get a good direction on where is the best way to spend time and energy. Of note, I've actually had my eye on a generic magic-method replacement mechanism for standard java that could be deployed as a maven plugin (or, if need be, a java 8 compiler plugin). I'd like to avoid dependency on a version of java not yet released, but, really, so long as it works, and I can fallback to suboptimal runtime operation (similar to how ServerGwtBridge will work if you initialize correctly), then I'm really open to anything. Given that APT and compiler plugins will be using the same Api, I can see the desire to move towards javax.lang.model now. I think, for now, I'm going to play with java 8 compiler plugins and see if my prejudice against javax.lang.model is ill placed. If you guys know of any other trees worth barking up, please do tell! -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
