AST Transformations - First Step to Heavy Substances

And let's do magic with your Java code. Here is this:


We take it:

import groovy.transform.Canonical import groovy.transform.TupleConstructor @Canonical @TupleConstructor class Person { int id String firstName String lastName Date birthdate } 

We compile, and in bytecode we get an analogue of this one:


Well, yes, it's nice. But nothing unique, here is Lombok , not to mention the ability of any good IDE to first generate and then hide all this boilerplate.
')
So why exactly Groovy, why AST transformations?
In this article I will try to justify in the short statement why to use Groovy AST transformations in Java projects, and (again, in brief) to tell what AST transfromations is in Groovy today. If you already know why, and want only "how and what", feel free to scroll to "Introduction to AST transformations".

So why AST transformations and not Lombok?

To begin with, in order to use AST transformations, you do not need to know Groovy, write on Groovy, or run Groovy in runtime. The transformation occurs during the compilation of the sorts and Groovy is added by one jar to the list of dependencies. Everything.
Thus, AST transformations are an excellent way to “push” Groovy into your project: “Look, boss, this is okay, this is just another library to fight the boiler back!”. And then, already, of course, step by step, a test on Spock, behind the build on Graydle, the real Groovy will appear in your code - dynamic, functional and elegant. AST transformations are just the first step.
In addition, AST transformations are much more extensible, powerful and versatile than Lombok.
Last but not least, AST transformations are perfectly supported in any IDE with Groovy support, and not just in Eclipse.
Lombok’s frontal comparison with AST transformations is clearly beyond the scope of this article, so let's stop here.

It seems to me to be taken for granted that the generation of bytecode has a huge advantage over the generation (and then “collapsing” in the editor so as not to put off an eye) of the source code - the generation occurs during compilation, it does not need to be “maintained”. One example - IntelliJ IDEA perfectly generates hashcode and equals. When adding a new field, I use these pens to erase these 2 methods and generate them again. Fu

There is much more to say about the benefits of AST transformations for both Java and Groovy developers, but I hope the idea is clear. It's time to move on to practice.

Introduction to AST transformations

One of Groovy's most important advantages is, of course, metaprogramming . It comes in two types - at compile time and at run time.
Metaprogramming during execution is about “ah, did you call a method that doesn't exist? No problem, we’ll think of something now, based on what you had in mind when you called this method. ” Examples of such a mass - almost any Groovy library is based on such things, whether it be builders, slarpers, Grails, Ratpack, Gradle, and everything else. But now it’s not about that (if you want it, see point 1 of brazen PR at the end of the post).

Now we will talk about metaprogramming during compilation, namely, how to simply write one in the code, to get another in bytecode (well, or additional).

We begin with the transformation that is stitched right in Groovy itself, without any annotations and other additions.
We write:

 class Person { String name } 

The output is a bytecode, in which all fields are private (in this case, name ), and all getters and setters are written (well, in this case, only getName() and setName(String name) , but the idea is clear).

This beautiful little thing is a complete example of metaprogramming at compile time.

Looking at this small escape from the boilerplate, the wonderful man Danno Ferrin said to himself: “But there are still a lot of boilerplate, besides the getters and setters, and not everyone has the same! Let's think of something that is connected and extensible! ”And so the AST Transformations were born (the first, oddly enough, was @Bindable . Although, if you look at how much code it throws, it may not be strange).

AST transformations are a set of annotations that change the abstract syntax tree on the fly during Groovy compilation. We can say that adding getters and setters is an embedded AST transformation that always works, without adding annotations. The rest is included only on demand.

Let's see what we have:

• So, the abstract pioneer @Bindable and her friend @Vetoable turn getters and setters into real properties, with the ability to hook listeners to them and listen, regarant and prohibit changes.
• Very fashionable now the words @Category and @Mixin add the nature of one class to another class. Well, impurities !
• @Delegate adds all the methods that the delegate has, implementing them, naturally, by the delegation, yes?
  We write:
  

   class Event { String name @Delegate Date date } 

  
  
  We get the delegation ready

   import java.util.Date; public class Event { private String name; private Date date; public String getName() { return this.name; } public void setName(String name) { this.name = name; } public Date getDate() { return this.date; } public void setDate(Date paramDate) { this.date = paramDate; } public boolean after(Date otherDate) { return date.after(otherDate); } public boolean before(Date otherDate) { return date.before(otherDate); } public long getTime() { return date.getTime(); } public void setTime(long timestamp) { date.setTime(timestamp); } } 

  
  
  
  
• @Immutable makes the class immutable, and specifically:
  
  1. Setters throw ReadOnlyPropertyException
  2. class becomes final
  3. fields become private and final
  4. constructors appear with all the fields: as simple as in parameters, so in map (as in the first example)
  5. A code appears that creates backups for the components being modified.
  6. appear equals , hashcode and toString
  
  
• Here is a bunch of similar fighters with a boilerplate: @InheritConstructors adds all constructors from the @TupleConstructor , @TupleConstructor adds a map constructor, in which keys are field names and values ​​are values ​​(see the first example of this @AutoClone ), @AutoClone and @AutoExternalize add the corresponding methods, and @Canonical does the “right Java class” - with a constructor without parameters, constructors that take all parameters (both in a row and mapa), and equals , hashCode and toString . Well, as @Immutable , only mutable - we also saw it in the first example.
• Another fashionable term! @Lazy will create a lazy-initialized field (on demand), optionally wrapped in soft-reference
• @Newify allows you to create objects using the new method instead of the name of the constructor (as in Ruby), or, conversely, only by the name of the constructor, without new (as in Python). Here, perhaps, an example would not hurt:
  

   @Newify rubyLikeNew() { assert Integer.new(42) == 42 } 

  
  or even
  

   @Newify([Tree, Leaf]) buildTree() { Tree(Tree(Leaf(1), Leaf(2)), Leaf(3)) } 

  
  In the last example, we create a Tree and Leaf without using new . Compare with the Java equivalent:
  

   public Tree buildTree() { return new Tree(new Tree(new Leaf(1), new Leaf(2)), new Leaf(3)); } 

  
  
• And here is a rectification of the old injustice: in Gruvy, by default all fields are public . How to make a package ? Through @PackageScope transformation!
• Regardless of whether you consider Singleton a pattern, or an anti-pattern, sometimes you have to write it. Well, or just put @Singleton over the class, and a lazily-initialized singleton with a double check of locking is ready.
• Our, # razborpoletov-ny Andrew wrote a wonderful, entered into @Memoized 2.2 @Memoized , which remembers the result of the method, and if it is called again, returns the result immediately (and yes, the parameters matter)
• And finally - the annotation-anecdote @NotYetImplemented - it reverses the results of the JUnit tests: those that should fall, pass, and vice versa. In addition, it reminds def true=false //happy debugging , this thing is useful for TDD - we throw tests for all methods, including those that are not yet registered, and force tests that should not yet and cannot work to pass with using @NotYetImplemented . Thus, the fall of these tests will not prevent us from testing the rest.

And that is not all! There is also an arch-important @CompileStatic , @Field , and a whole set of annotations for the endowment of suffering for concurency, but this is, all the same, another time (well, or, see point 1 of brazen PR at the end of the post).

PS Now that you know what it is about, here are two interesting Habra articles about how and what to write new AST transformations. About the same look below, in paragraph 2 of the brazen PR.

And now brazen PR of 2 points:

1. Who needs Gruvey from scratch to sufficiently advanced support, let's go to my trainings, April 17th in Moscow and April 15th in Kazan (knock alexbel )
2. To whom are the abstract syntax tree dismemberments and writing your own AST transformations to fight your own cockroaches with boilerplays, go to my reports at the JPoint on April 18th and on JavaDay Kazan on April 16th (knock alexbel again)