On Thu, Feb 27, 2014 at 8:07 PM, James Nelson <ja...@wetheinter.net> wrote:
>
>>> 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.
>
Global access to subtypes is one of the things we would like to avoid - as
it is by definition requires a global pass.
> Of course, the classpath for these utilities are unbounded, so gwt.xml
> inclusion/exclusion will essentially be ignored.
>
I'm not sure why this would matter. You are basically supplying source code
to GWT and some is provided via APT. GWT doesn't care how you create those.
> 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 think one strong option is to provide runtime access to properties so
that you can generate code that checks the property - that is
separate-compile friendly and output is optimizable in global pass.
>
>
>> 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).
>
>
There is no reason to implement the magic method replacement mechanism
itself via APT - it will be implemented inside the compiler and will access
to whatever we have accesses.
Think about it as a lightweight code generator mechanism supported bt the
GWT compiler where you could access constant values to generate some simple
statements. For example: GWT.create() based on APT can be emulated with
such mechanism. e.g.:
class A {} // user class
class A_Impl // generated with APT
GWT.create(A.class) calls are replaced with new A_Impl() by the
magic-method replacement. To implement such a generator you only need very
basic type information.
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?
>
>
Probably. To be honest, I don't know the current state of the art for APTs
and if there are any good libraries already available. But the good part
is, what you do is going to be useful for all java apps, not only GWT.
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 .
>
Pls see my earlier comment.
> 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?
>
>
Just to be clear, we are not deprecating GWT code generators - they will
not be gone soon.
However, given that we've proved APTs, we can highly encourage people to
use them and we can put our energy towards that. My vision here is to
enable GWT apps to be written without classic generators and can achieve
very short refresh times with the added benefit of code portability with
Android and j2objc.
> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
