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
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
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 AutoValue.
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 lombok
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/server.
On Fri, Feb 28, 2014 at 5:52 AM, Andrés Testi andres.a.te...@gmail.comwrote:
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
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 use
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
andres@gmail.comjavascript:
wrote:
Please, don't adopt Lombok. While it is an interesting project, it is
still a hack. We should wait for java8 compiler plugins,
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 to
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
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
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 andres.a.te...@gmail.comwrote:
Hi contribs:
Are you aware of Square's
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.
--
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 ja...@wetheinter.net wrote:
Is there
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,
On Thu, Feb 27, 2014 at 4:17 PM, James Nelson ja...@wetheinter.net 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
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
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
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.
20 matches
Mail list logo
