Take a look at this comment of Kevin Bourillion about we they dislike
Lombok. I couldn't have said It
better:
http://www.reddit.com/r/java/comments/1y9e6t/ama_were_the_google_team_behind_guava_dagger/cfjf5v5
- Andrés Testi
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
>
> BTW, it is unlikely we will adopt lombok.
>
Nice to hear it.
> Hopefully, the way this works in your IDE is that the moment you create
> the JsInterface and hit Save, APT will run and create the magic _prototype
> class, and then you can start writing your Web Component or JS-subtype in
BTW, it is unlikely we will adopt lombok. We only considered it because the
JS Interop stuff depends on a 'magic' .Prototype class, and you cannot use
APT to inject subclasses into another existing class, but Lombok can
because it can rewrite classes. However we got deeply burned by DevMode
dependi
>
>
> SourceWriter is not incompatible with APT, just like JavaWriter is not
> incompatible with generators. Both take a PrintWriter where they write;
> SourceWriter is string-based with only a few helpers for javadoc and
> indent/outdent, whereas JavaWriter is more "Java oriented" with methods
On Friday, February 28, 2014 8:50:03 PM UTC+1, Goktug Gokdogan wrote:
>
>
>
>
> On Fri, Feb 28, 2014 at 5:52 AM, Andrés Testi
>
> > wrote:
>
>> Please, don't adopt Lombok. While it is an interesting project, it is
>> still a hack. We should wait for java8 compiler plugins, because they are
>>
>
> Deprecating SourceWriter and replacing it with JavaWriter means
> encouraging our users (and our own code-base) to move out of SourceWriter
> to JavaWriter.
> If we decide APT is the way to go then if someone is going to write
> generator, it should be APT - in that case internally we may
On Fri, Feb 28, 2014 at 5:52 AM, Andrés Testi wrote:
> Please, don't adopt Lombok. While it is an interesting project, it is
> still a hack. We should wait for java8 compiler plugins, because they are
> an official feature and have a lot more probabilities than lombok to be
> forward compatible an
On Friday, February 28, 2014 5:07:04 AM UTC+1, James Nelson 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/serve
On Friday, February 28, 2014 2:52:35 PM UTC+1, Andrés Testi wrote:
>
> Please, don't adopt Lombok. While it is an interesting project, it is
> still a hack.
>
+1000
> We should wait for java8 compiler plugins, because they are an official
> feature and have a lot more probabilities than lom
On Friday, February 28, 2014 2:08:08 AM UTC+1, Brian Slesinsky wrote:
>
> I believe it's just an idea. In practice, we have lots of GWT generator
> code that's not easily migrated.
>
> I'm not familar with APT but if I wanted to learn about it I would
> probably start by studying Guice's AutoVa
Please, don't adopt Lombok. While it is an interesting project, it is still
a hack. We should wait for java8 compiler plugins, because they are an
official feature and have a lot more probabilities than lombok to be
forward compatible and standardized. Ironically, Reinier Zwitserloot, one
of th
On Thu, Feb 27, 2014 at 8:07 PM, James Nelson 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 basi
An excellent read about the trick behind Lombok, and related ast-hacking
utils:
http://notatube.blogspot.ca/2010/11/project-lombok-trick-explained.html
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups
>
>
>> 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 n
On Thu, Feb 27, 2014 at 4:17 PM, James Nelson wrote:
> Is there anywhere to get a sneak preview on the discussions about the
> future of codegen?
>
>
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 in
I believe it's just an idea. In practice, we have lots of GWT generator
code that's not easily migrated.
I'm not familar with APT but if I wanted to learn about it I would probably
start by studying Guice's AutoValue. If they're using JavaWriter then
that's a good endorsement.
- Brian
On Thu, Fe
I think if we move to APT, you can do AST based code-gen via something like
a JavaWriter to a stream, or if we adopt lombok, then you construct code by
directly manipulating the trees of JavaC and JDT.
On Thu Feb 27 2014 at 4:17:15 PM, James Nelson wrote:
> Is there anywhere to get a sneak pr
Is there anywhere to get a sneak preview on the discussions about the
future of codegen?
Andres and I have both invested time in some extensions of ast-based
codegen, and could really use some time and forewarning to adapt our
strategy to stay future-friendly with out apis.
--
http://groups.g
This has been discussed earlier but in general we would like to move to APT
for codegen - with that developers could use any existing lib/framework
that they see a fit.
On Thu, Feb 27, 2014 at 7:06 AM, Andrés Testi wrote:
> Hi contribs:
>
> Are you aware of Square's JavaWriter API? (
> https://g
Hi contribs:
Are you aware of Square's JavaWriter API?
(https://github.com/square/javawriter). It comes from the
Dagger/Guice/Guava team, and is widely used for code generation (Dagger,
AutoFactory and AutoValue
What do you think about introduce this dependency as replacement for
SourceWriter
20 matches
Mail list logo
