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 <ja...@wetheinter.net> 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/
> <groupId>net.wetheinter</groupId>
> <artifactId>xapi-dev-source</artifactId>
> <version>0.4</version>
>
> 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<Object> b = new SourceBuilder<Object>(
> "public static abstract class Test");
> b.setPackage("xapi.test");
> b.getClassBuffer()
> .createMethod("public <T extends java.util.Date> 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("<T extends Date>"));
> // 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, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
