AspectJ fait très bien l'affaire pour Fonzie mais apporte de nombreuses contraintes :
- la compilation n'est pas des plus véloces,
- l'environnement de dev AJDT est particulièrement gourmand,
- le plugin AspectJ doit être configuré dans le build Maven.
L'idée de Julien est de détourner APT pour s'intégrer directement dans la compilation JavaC, ce qui est possible depuis Java6 avec une API standard. En utilisant des API internes de javac (com.sum.tools*) on peut faire plus que transformer les annotations en fichiers de ressources ou en nouveau code Java -- l'objectif initial d'APT. On peut aller directement modifier le code source qui va être compilé - sa représentation AST plus précisément - sans toucher pour autant au fichier source.
Lombok utilise ce principe pour ajouter des getter/setter (entre autre) dans les beans. Plus besoin de polluer le code .java avec ces méthodes sans valeur, qui seront bel et bien présentes dans le code compilé.
Ca, c'est la théorie.
Reste à mettre en oeuvre. Même avec l'aide du code source de Julien (chromattic, reflext) et de Lombok, la manipulation des ces API internes est délicate, et leur code source n'est pas proposé dans le SRC.ZIP qui accompagne le JDK. Il y a heureusement google et OpenJDK pour retrouver ces sources, mais bien peu d'infos sur comment utiliser ces APIs.
Toujours est-il qu'un premier jet bien modeste - mais faut bien commencer par quelque chose - est en place. Sur la base de ce code source :
@EntityPour un projet utilisant le JDK6 pour compiler, et sans rien faire sauf ajouter Fonzie-0.4-SNAPSHOT en dépendance, le fichier .class décompilé donne ceci :
public class User
{
public native void persist();
}
@EntityPour ce premier jet, le code introduit dans la méthode n'est pas passionnant, mais au moins le squelette est en place. Reste à construire via l'AST le code d'invocation Fonzie qui va bien -- et ça, ça va être tout de suite plus toochy.
public class User
{
public void persist()
{
Fonzie.instance();
}
}
Wait & See ...
