Groovy Metaprograming (Spanish version)

Jose Juan MontielJose Juan Montiel

Generation of code. From the model to the view.

Well, at last, more than 9 months after its beginning, I have encouraged to finish this blog post, and it was after the tweet of @jagedn that after the @ilopmar talk in madridgug, he encouraged me with asteroid.

But hey, by order.

In one of my other articles, talked about how, using Groovy and Thymeleaf, one could to separate even a little more, the model of the view of where to place the binding elements, to display model data; and leave some next steps, how you could generate part of that code.

And I will not talk about how to generate this code in this post, it should be more forward but at least, I will list a number of "useful" links to generate code.

To date, there are many ways to "generate code". For example in this article Ivan tells us the options that are in groovy (at compile time, and in A previous one, those of execution time).

And in this talk, Mario, focuses on the aids that exist for Metaprogramming in groovy, macros. And it also tells us about a library to help us in this process of creating Macros: asteroid

If we had to make a classification, different, in different ways to create code we could do it like this:

  1. Those of "java"

    1. The ones that you can see

      1. Those that generate source code

        • Things like Spring Roo or Yeoman or the most current JHipster are tools that generate code "scaffolding".

        • But things like this library Javapoet generates source code, from a DSL, and so we start from a common sources.

      2. Those that generate code "compiled". APT, Is the tool on which the "rest" that modifies the AST.

        • By example, this library, MagicBuilder generate code at compile time, following the patron builder.

      3. Those that modify the bytecode

    2. Those that "do not" look

      1. Those that use dependency injection.

        • At the end declare a variable, and that in execution time it has been assigned a value, is also a way to modify the code. Here too Would have a place, that kind of thing that, among others, makes Spring to generate the beans that injects us through proxies for example.

      2. AspectJ / AOP

        • This, somehow modifies the code / ast / bytecode, but the peculiarity is the way to define where these transformations are going to take place. Could considered a kind of global AST.

      3. Lombock

        • It is for those who can not use Groovy, at least, do not have they do certain things that are always the same, like the getter / setter. This clearly enters in the AST field.

    3. Those that modify the code "loaded" in one "environment" by another

    4. Those that change the code in production through dinamic attach. Dynamic attach.

      • In this talk, we are told how to use YouDebug as an interactive debugger in production.

    5. Those that compile code from sources in production. Compile sources en runtime.

  2. The android world

    1. Assisted by gradle (with the APT plugin)

  3. Osgi vs Jigsaw Hehe, well, this for another day :)

And well, so you do not make "ball" this blog entry, simply reflect "The different ways to" generate code "that exist in the world of the JVM (java, groovy) any more?

Extra ball

Some conversations in stackoverflow about android, groovy and code generation by APT

  1. http://stackoverflow.com/questions/31536234/android-annotations-multiple-paths-to-apt

  2. http://stackoverflow.com/questions/30991656/what-its-the-first-the-annotated-class-egg-or-used-class-chicken

  3. http://stackoverflow.com/questions/31160831/android-groovy-android-annotation