Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[Ray Cromwell]

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
depending on undocumented browser native APIs and we'd like to avoid
depending on non-official APIs to make a core feature work.

Since APT is supported by all Java tools, and already works with
@AutoValue, we are likely to use it for the magic Prototype stuff, it just
will be less pretty, e.g.

@JsInterface(prototype = 'HTMLButtonElement')
interface HTMLButtonElement {
}

class GangnamButton extends HTMLButtonElement_prototype {
...
}

// auto-generated by APT
class HTMLButtonElement_prototype implements HTMLButtonElement {
}


My argument for using "_" is that using _ in Java class names is
unconventional and clearly denotes a special class, generated, that you
shouldnt touch. Also, @AutoValue also uses "_" in the name for the same
reason.


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
Java by extending it without red squigglies.

Lombok by contrast required seperate Java IDE plugins for IntelliJ and
Eclipse to make this happen.



On Fri, Feb 28, 2014 at 4:59 PM, James Nelson  wrote:

>
>> 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
>> begin/end types, methods, control flow blocks, fields, etc.
>>
>
>  Not to shamelessly plug my own work or anything, but I do maintain a
> SourceBuilder library that contains piles of helper functions, the ability
> to add method or field buffers that effectively tear-off a position in the
> source writer, so you can build multiple methods at the same time; it uses
> all fluent interfaces, automatically imports classes (returning the
> shortest name possible that can be used in code [fully qualified if import
> name is already taken]), has fluent interfaces for all methods, and has
> simple support for jsni.
>
>
> https://github.com/WeTheInternet/xapi/blob/master/dev/source/src/main/java/xapi/dev/source/
> net.wetheinter
> xapi-dev-source
> 0.4
>
> It looks something like:
>
> MethodBuffer valueProvider = beanCls
> .createMethod("protected Object valueOf(String name, Object o)")
> // definition is lexed; it can be modified later if you desire
> .setUseJsni(true)
> .addAnnotation(UnsafeNativeLong.class)
> .println("switch(name) {")
> .indent()
> .println("case 'this': return o;")
> .println("case 'this.name()':")
> .indentln("return o...@java.lang.Object
> ::getClass()().@java.lang.Class::getName()();");
>
> Or, here's a test with more features:
>
> SourceBuilder b = new SourceBuilder(
>   "public static abstract class Test");
> b.setPackage("xapi.test");
> b.getClassBuffer()
>   .createMethod("public  void
> Test(java.lang.String t) {")
>   .indentln("System.out.println(\"Hellow World\" + new
> java.sql.Date());")
>   .createLocalClass("class InnerClass ")
>   .createMethod("void innerMethod()")
>   ;
> // We discard java.lang imports
> Assert.assertFalse(b.toString().contains("import java.lang.String;"));
> // We used java.util.Date as a fully qualified name first, so it
> should be imported
> Assert.assertTrue(b.toString().contains("import java.util.Date;"));
> Assert.assertTrue(b.toString().contains(""));
> // We used java.sql.Date as a fqcn after java.util.Date, so it must
> NOT be imported
> Assert.assertFalse(b.toString().contains("import java.sql.Date;"));
>
> At the core, it's based on StringBuilder, and it takes the best of
> SourceWriter and JavaWriter, then adds a bunch of shiny on top.
> It's mutable, supports the notion of ClassBuffer, MethodBuffer and
> FieldBuffer, with child writers scoped correctly, to make inner classes or
> even local classes that retain their place in the SourceBuilder stack.
>
> --
> 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,

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[James Nelson]

>
>
> 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 
> begin/end types, methods, control flow blocks, fields, etc.
>

 Not to shamelessly plug my own work or anything, but I do maintain a 
SourceBuilder library that contains piles of helper functions, the ability 
to add method or field buffers that effectively tear-off a position in the 
source writer, so you can build multiple methods at the same time; it uses 
all fluent interfaces, automatically imports classes (returning the 
shortest name possible that can be used in code [fully qualified if import 
name is already taken]), has fluent interfaces for all methods, and has 
simple support for jsni.

https://github.com/WeTheInternet/xapi/blob/master/dev/source/src/main/java/xapi/dev/source/
net.wetheinter
xapi-dev-source
0.4

It looks something like:

MethodBuffer valueProvider = beanCls
.createMethod("protected Object valueOf(String name, Object o)") // 
definition is lexed; it can be modified later if you desire
.setUseJsni(true)
.addAnnotation(UnsafeNativeLong.class)
.println("switch(name) {")
.indent()
.println("case 'this': return o;")
.println("case 'this.name()':")
.indentln("return 
o...@java.lang.Object::getClass()().@java.lang.Class::getName()();");

Or, here's a test with more features:

SourceBuilder b = new SourceBuilder(
  "public static abstract class Test");
b.setPackage("xapi.test");
b.getClassBuffer()
  .createMethod("public  void 
Test(java.lang.String t) {")
  .indentln("System.out.println(\"Hellow World\" + new 
java.sql.Date());")
  .createLocalClass("class InnerClass ")
  .createMethod("void innerMethod()")
  ;
// We discard java.lang imports
Assert.assertFalse(b.toString().contains("import java.lang.String;"));
// We used java.util.Date as a fully qualified name first, so it should 
be imported
Assert.assertTrue(b.toString().contains("import java.util.Date;"));
Assert.assertTrue(b.toString().contains(""));
// We used java.sql.Date as a fqcn after java.util.Date, so it must NOT 
be imported
Assert.assertFalse(b.toString().contains("import java.sql.Date;"));

At the core, it's based on StringBuilder, and it takes the best of 
SourceWriter and JavaWriter, then adds a bunch of shiny on top.
It's mutable, supports the notion of ClassBuffer, MethodBuffer and 
FieldBuffer, with child writers scoped correctly, to make inner classes or 
even local classes that retain their place in the SourceBuilder stack.

-- 
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.

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[Thomas Broyer]

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 
>> an official feature and have a lot more probabilities than lombok to be 
>> forward compatible and standardized. Ironically, Reinier Zwitserloot, one 
>> of the authors of Lombok, disagreed with me when I proposed Annotation 
>> Proccessors as replacement for generators, 7 years ago: 
>> https://groups.google.com/d/msg/google-web-toolkit-contributors/2uBiRzMJLgM/v0tX_DXEv6oJ
>>
>> My original intention with this post, was to deprecate a redundant 
>> feature like SourceWriter. While the suggested way to go would be APT (I'm 
>> not really convinced about it), GWT.create() will stay here for years. I 
>> can't see incompatibility between adoption of APT and deprecation of 
>> SourceWriter. Promoting the use of tools like JavaWriter instead of 
>> GWT-only features, is a good sign for developers to go for other options. 
>> Less code to mantain is better.
>>
>
> 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 JavaWriter 
> and externally they could use whatever they want (including the JavaWriter).
>

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 
begin/end types, methods, control flow blocks, fields, etc.

-- 
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.

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[Andrés Testi]

>
> 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 JavaWriter 
> and externally they could use whatever they want (including the JavaWriter).
> However, If the generator is already written, then it is a meaningless 
> effort to move out of SourceWriter.
> All of these together there is very little value compared to the cost of 
> such move (including the annoyance caused by it).
>

Deprecation doesn't implies removal. It could stay deprecated forever, 
discouraging people to use it for new developments. We don't have yet 
evidence that APT is able to cover all the Generator use cases.  Anyway, as 
Thomas said, we should priorize modularization.

- Andrés Testi

-- 
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.

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[Goktug Gokdogan]

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 and standardized. Ironically, Reinier Zwitserloot, one
> of the authors of Lombok, disagreed with me when I proposed Annotation
> Proccessors as replacement for generators, 7 years ago:
> https://groups.google.com/d/msg/google-web-toolkit-contributors/2uBiRzMJLgM/v0tX_DXEv6oJ
>
> My original intention with this post, was to deprecate a redundant feature
> like SourceWriter. While the suggested way to go would be APT (I'm not
> really convinced about it), GWT.create() will stay here for years. I can't
> see incompatibility between adoption of APT and deprecation of
> SourceWriter. Promoting the use of tools like JavaWriter instead of
> GWT-only features, is a good sign for developers to go for other options.
> Less code to mantain is better.
>

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 JavaWriter
and externally they could use whatever they want (including the JavaWriter).
However, If the generator is already written, then it is a meaningless
effort to move out of SourceWriter.
All of these together there is very little value compared to the cost of
such move (including the annoyance caused by it).


> A quick example:
> Generator.escape() doesn't escapes UTF-8 control characters. To fix it, I
> must write a patch, pray for its approbation, and wait for the next GWT
> release. Or I can just use JavaWriter.stringLiteral() .
>
> - Andrés Testi
>
> El jueves, 27 de febrero de 2014 22:02:14 UTC-3, Ray Cromwell escribió:
>>
>> 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 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.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.
>

-- 
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.

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[Thomas Broyer]

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. 
>> 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.
>

And then there's ElementFilter to easily extract those things you're 
interested in.
 

> 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.
>

I think one of the goals of extracting interfaces in 
c.g.g.core.ext.typeinfo at some point was to allow implementing them on top 
of javax.lang.model, so that GWT generators could possibly run as APT 
processors (or eventually using runtime javax.lang.model implementation: 
http://openjdk.java.net/jeps/119). It might be impossible (or only 
partially possible) though.

-- 
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.

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[Thomas Broyer]

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 to be forward 
> compatible and standardized. Ironically, Reinier Zwitserloot, one of the 
> authors of Lombok, disagreed with me when I proposed Annotation Proccessors 
> as replacement for generators, 7 years ago: 
> https://groups.google.com/d/msg/google-web-toolkit-contributors/2uBiRzMJLgM/v0tX_DXEv6oJ
>
> My original intention with this post, was to deprecate a redundant feature 
> like SourceWriter. While the suggested way to go would be APT (I'm not 
> really convinced about it), GWT.create() will stay here for years. I can't 
> see incompatibility between adoption of APT and deprecation of 
> SourceWriter. Promoting the use of tools like JavaWriter instead of 
> GWT-only features, is a good sign for developers to go for other options. 
> Less code to mantain is better.
> A quick example:
> Generator.escape() doesn't escapes UTF-8 control characters. To fix it, I 
> must write a patch, pray for its approbation, and wait for the next GWT 
> release. Or I can just use JavaWriter.stringLiteral() .
>

That's only until we modularize GWT. We'll then be able to extract 
SourceWriter into its own lib with its own release cycle.
 

>
> - Andrés Testi
>
> El jueves, 27 de febrero de 2014 22:02:14 UTC-3, Ray Cromwell escribió:
>>
>> 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 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.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.

[gwt-contrib] Re: JavaWriter API as replacement for SourceWriter family

[Andrés Testi]

Nice!

- Andrés Testi

El viernes, 28 de febrero de 2014 15:11:35 UTC-3, Thomas Broyer escribió:
>
>
>
> On Friday, February 28, 2014 5:35:41 PM UTC+1, Andrés Testi wrote:
>>
>> However I think that JavaWriter is still a valid option for non JSNI 
>> code, and the API will evolve to support more use cases.
>>
>
> Sure, and the proposed JavaWriter 3.0 
> APIcould
>  possibly allow subclassing to provide a JsniMethod.
>

-- 
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.

[gwt-contrib] Re: JavaWriter API as replacement for SourceWriter family

[Thomas Broyer]

On Friday, February 28, 2014 5:35:41 PM UTC+1, Andrés Testi wrote:
>
> However I think that JavaWriter is still a valid option for non JSNI code, 
> and the API will evolve to support more use cases.
>

Sure, and the proposed JavaWriter 3.0 
APIcould 
possibly allow subclassing to provide a JsniMethod.

-- 
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.

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[Thomas Broyer]

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. If they're using JavaWriter 
> then that's a good endorsement.
>

AutoValue doesn't use JavaWriter, they use their own Template (no idea 
why): 
https://github.com/google/auto/blob/master/value/src/main/java/com/google/auto/value/processor/Template.java
AutoFactory does use JavaWriter though (and as has been said before, Dagger 
uses JavaWriter too –JavaWriter started its life within Dagger before being 
spun off into its own lib–, as does Wire –AFAICT, the reason why JavaWriter 
was extracted into an independent lib–)

-- 
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.

[gwt-contrib] Re: JavaWriter API as replacement for SourceWriter family

[Andrés Testi]

Thanks Thomas! I appreciate your response.
I thought that JSNI could be implemented with beginControl("public native 
void foo()/*-"); , but JavaWriter checks for open scopes. However I think 
that JavaWriter is still a valid option for non JSNI code, and the API will 
evolve to support more use cases.

- Andrés Testi

El viernes, 28 de febrero de 2014 11:07:59 UTC-3, Thomas Broyer escribió:
>
> JavaWriter has many small limitations, and in the case of GWT, the main 
> one is that it's impossible to make it emit JSNI methods (other limitations 
> include: annotations on method arguments, and generic/parameterized 
> methods).
> It's a really great lib, but I believe it'll never support JSNI (I doubt 
> Jesse/Jake would accept adding support for it; on the other hand, JSNI as 
> we know it is about to disappear if I understood Goktug properly)
>
> On Thursday, February 27, 2014 4:06:46 PM UTC+1, Andrés Testi wrote:
>>
>> 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 family in order to reduce GWT core and increase compatibility 
>> with external tools?
>>
>> - Andrés Testi
>>
>

-- 
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.

[gwt-contrib] Re: JavaWriter API as replacement for SourceWriter family

[Thomas Broyer]

JavaWriter has many small limitations, and in the case of GWT, the main one 
is that it's impossible to make it emit JSNI methods (other limitations 
include: annotations on method arguments, and generic/parameterized 
methods).
It's a really great lib, but I believe it'll never support JSNI (I doubt 
Jesse/Jake would accept adding support for it; on the other hand, JSNI as 
we know it is about to disappear if I understood Goktug properly)

On Thursday, February 27, 2014 4:06:46 PM UTC+1, Andrés Testi wrote:
>
> 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 family in order to reduce GWT core and increase compatibility 
> with external tools?
>
> - Andrés Testi
>

-- 
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.

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[Andrés Testi]

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 the authors of Lombok, disagreed with me when I proposed Annotation 
Proccessors as replacement for generators, 7 years 
ago: 
https://groups.google.com/d/msg/google-web-toolkit-contributors/2uBiRzMJLgM/v0tX_DXEv6oJ

My original intention with this post, was to deprecate a redundant feature 
like SourceWriter. While the suggested way to go would be APT (I'm not 
really convinced about it), GWT.create() will stay here for years. I can't 
see incompatibility between adoption of APT and deprecation of 
SourceWriter. Promoting the use of tools like JavaWriter instead of 
GWT-only features, is a good sign for developers to go for other options. 
Less code to mantain is better.
A quick example:
Generator.escape() doesn't escapes UTF-8 control characters. To fix it, I 
must write a patch, pray for its approbation, and wait for the next GWT 
release. Or I can just use JavaWriter.stringLiteral() .

- Andrés Testi

El jueves, 27 de febrero de 2014 22:02:14 UTC-3, Ray Cromwell escribió:
>
> 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 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.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.