Casper: It doesn't have to be legal java, it just has to pass the AST
build phase. So, this:
new _($1, $2) {{ return String; }}
looks like gibberish but the parser will make something out of this
(Anonymous Inner Class literal, creating a new instance of (non-
existent) type "_", passing (non-existent) variables $1 and $2 to the
(non-existent) constructor of _, then supplying implementations for no
methods, but having an instance initializer that has an (illegal, in
that place) return statement, returning a (non-existent) variable
named 'String'. So, that WOULD work. Unfortunately, I'm fairly sure
the parser absolutely needs 2 subsequent identifiers in a parameter
slot in a method declaration, or it'll get very confused.
However, the parser can be lenient sometimes. For example, '.' is not
legal in a java identifier, but if you replace the 'return String'
with 'return java.lang.String;' in the above example, the parser WILL
take the entire 'java.lang.String' as identifier, in both javac and
eclipse. You have to find this stuff out by trial and error. There's a
special annotation for this that can help you out:
@lombok.core.PrintAST(printContent=true/false). Stick it on a class or
on a method and lombok will print the entire AST to System.out. For
eclipse, this means you have to start eclipse from a dosbox on
windows, or from the terminal on mac/linux, so you can see what its
printing (alternatively, supply a value for the outFile parameter and
lombok will print to a file). with printContent=true, it'll print java
code, with printContent=false, it'll print a nested XML-esque listing
of AST nodes. If some non-legal java nevertheless produces an AST that
has all the information you need and is sufficiently unique that a
lombok transformation is unlikely to mistake legal java code for your
new language construct, lombok can do it. You can use the same trick
to see what lombok has cooked up (as PrintAST is hardcoded to always
run last).
Plans to allow you to redefine the language are sort of on the table,
but the major hurdle here is javac: Our current injection trick
(annotation processor) doesn't run early enough in the compilation
process to change javac's internal tree nodes (The JCTree class, for
those who are familiar with javac internals). The only mechanism that
would do the job that I can think of, is java agents. This is
possible, but makes working with tools like ant or maven rather
difficult; you'd have to ask those tools to pass a JVM argument *and*
fork when running javac, or you have to hack tools.jar - these are
both steps that would drastically lower lombok's easy-of-use in your
build system.
Technically, even with utterly bogus ASTs, the annotation processor
does usually still get called, and you can technically get at the raw
source. So, lombok COULD ship with its own modded javac (think
kijaro), and duplicate javac's parsing efforts, then replace the
entire AST tree javac made with the one the internal kijaro made. This
might work - I'd have to do a lot more research before I can be sure.
For the IDEs, as the injection mechanism is already java agents, you
can definitely modify the parser so it'll parse whatever language
construct you can think of, so javac is really the only major hurdle
to do it.
Thanks for the support. To be honest, I was expecting a lot more of:
"Whoa! Whoa! What the HECK did you do to my java, you cretin! This is
madness! Annotations must not be used this way! Get the torches and
pitchforks!" (reading coindev, the project coin mailing list, can make
one cynical...)
On Jul 31, 2:57 am, Casper Bang <[email protected]> wrote:
> Congrats on realizing your idea. Feels a little bit like a poor mans
> solution to a problem better handled elsewhere, but since that's a no-
> go this is definitely very cool! I'm curious, could I use Lombok to
> implement Anonymous Parameters <http://docs.google.com/Doc?
> id=dfkvb9sc_0pcr8szdd> or does Lombok require valid Java to append/
> substitute in the AST? (Will the javac annotation processing be
> allowed on an invalid code block?)
>
> /Casper
>
> On 29 Jul., 14:11, Reinier Zwitserloot <[email protected]> wrote:
>
>
>
> > It should - the class files it generates are indistinguishable from
> > boilerplate written out in full. For the same reason, it should play
> > nice with other eclipse plugins as well. it's definitely going to
> > choke if something that uses the same trick as project lombok is also
> > running on your eclipse, but as far as I know, lombok is the only
> > project crazy enough to 'plug into' eclipse by way of java agents :)
>
> > On Jul 29, 1:38 pm, Mwanji Ezana <[email protected]> wrote:
>
> > > This looks awesome! Can't wait to try it out (which, unfortunately,
> > > will only be in a week or two...).
>
> > > Does Lombok play nicely with bytecode enhancement, weaving, etc.?
>
> > > Moandji
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
