[Annotations] Génération de code de délégation

**behess** · 05/01/2011, 12h29

Bonjour,

ce post fait suite à cette discussion sur la délégation en java.

Je présente de nouveau l'idée brièvement : le but est de créer une annotation de variable d'instance ou de classe (Delegate) qui permette de générer les délégués à la compilation (via APT).

Ici j'aimerais que vous puissiez m'aider à réaliser cette solution.

J'ai déjà un prototype qui ne génère rien mais qui analyse le code et remonte des erreurs.

Je dois tester ce premier jet, mais c'est surtout l'étape de la génération qui me poserait problème, je ne sais pas du tout comment faire... ni même si c'est possible !

**behess** · 06/01/2011, 17h26

Pour ceux que ça intéresse...

Je pense générer de nouveaux fichiers, tout simplement.

Je compte aussi passer par une tâche Ant :

1°) APT => generation de nouveaux fichiers source (.machintruc pour ne pas perturber les sources originales) avec delegation

2°) preparation des sources (remplacement des sources originales)

3°) compilation/build

4°) restauration des sources (on remet les sources originales)

Je ne vois pas d'autre solution pour le moment ; par contre je ne suis pas calé en Ant, je vais donc aller m'instruire pour voir où ça va me mener.

**kimjoa** · 06/01/2011, 18h08

salut ! je peux pas t'aider, mon niveau est ce qu'il est

, mais je trouve ton idée pas mal. J'ai lue que java8 définit une spécification de développement modulaire.... J'ai sais pas ce que ça veux dire ... , , peux être l'implémentation des mixin comme en java fx .... bref je sais pas si ce code pourrait t'aidé mais je me suis penché sur le problème des mixin dernièrement, et trouvé une classe sympa, et surtout assez simple, au vue des autres projet similaire ...

http://berniesumption.com/software/mixins-for-java/

J’espère que ça t'aidera

bye

**professeur shadoko** · 06/01/2011, 18h24

note: on n'utilise plus vraiment APT on passe des AnnotationProcessor au compilateur. voir doc ...

**Alain Defrance** · 06/01/2011, 19h29

Les annotations processor c'est cool, ça éviter les pre/post compilation.
Ça serait donc cool de ne pas ajouter ant pour faire ça

Pourquoi ne pas générer un fichier via le filer au niveau de l'annotation processing ?
Pourquoi ne pas générer directement des .java ?

Le fait de passer par le filer t'éviteras t'avoir plusieurs steps pour ta compilation et tu n'auras pas à lancer la compilation de tes fichiers générés.

Le filer permettra de détectera la création de nouveaux type et javac balancera un nouveau round de compilation.

Courage tu va t'en sortir, c'est pas le plus simple à faire

**behess** · 07/01/2011, 10h05

Merci pour vos réponses

Je ne connais pas ces éléments, je vais étudier ça de ce pas, ça semble intéressant (j'apprends plein de trucs en ce moment).

**Alain Defrance** · 07/01/2011, 11h13

Envoyé par behess

j'apprends plein de trucs en ce moment

Je te souhaite de ne jamais arreter

**behess** · 07/01/2011, 23h51

Alors d'après ce que j'ai compris : l'extension APT a été intregre dans javac depuis Java 6. On utilise le package javax au lieu de mirror et on n'a plus besoin de factory ou de visitor et on implémentés directement un AnnotationProcessor qu'on passe au compilateur. On peut écrire de nouveaux fichier en phase compilation, qui pourront eux même être analyses. On peut modifier du bytecode (donc déjà compile) avant l'exécution a l'aide d'un agent instrument ou même exécuter des méthodes par réflexion lors de l'exécution.

C'est cool tout ça

Mais je n'ai rien trouve qui me dise comment intervenir avant/après compilation (en fait avant je dois pouvoir le faire a l'aide du processor...) afin de préparer/repositionner mes fichiers.

Auriez-vous des références (en ligne si possible) qui m'explique ça ?

**behess** · 09/01/2011, 01h36

apparemment l'annotation processor intervient bien avant la compilation.
Il ne semble pas y avoir moyen de pluguer une étape apres la compilation. Donc le remplacement et la restauration de source, hors Ant faut oublier.

Par contre j'ai trouvé un article intéressant sur un hack de javac permettant de modifier l'arbre interne reprentant le source avant son traitement par le générateur de byte code. C'est exactement ce dont j'ai besoin. Et cerise sur le gateau on peut enregistrer le processor comme un service permanent de javac : même plus besoin d'ajouter une option a javac ! on peut donc utiliser l'IDE comme d'habitude et tout se fait tout seul

Bon ce n'est encore que de la théorie, il reste la mise en œuvre ! ( ça ne fonctionnerait qu'avec le compilo de sun, mais tant pis c'est le seul que j'utilise). Je vais pondre une JSR pour demander de rendre ce hack officiel tient, comme ça ça pourra être utilise dans tous les compilos

**Alain Defrance** · 11/01/2011, 09h19

Salut,

Pour un exemple tu peux regarder ça : http://chromattic.googlecode.com/svn...hromattic/apt/

Pour remplacer une resource existante, il est peut être possible de hacker javac mais ca reste du hack. Pour notre part quand on modifie une resource on charge dynamiquement une autre resource via un classloader custom.

courage

**Alain Defrance** · 11/01/2011, 09h22

Tu peux regarder également ça : https://github.com/vietj/aptvir
Qui utilise apt pour répliquer un processus qui se copie à la compile pour se répande dans divers projets. C'est juste une démo technique qui montre un genre de virus basé sur la compilation.

On se base sur le principe que personne compile avec un SecurityManager et qu'on peut s'amuser avec des setAccessible(true)

**behess** · 11/01/2011, 10h47

Envoyé par Alain Defrance

Salut,

Pour un exemple tu peux regarder ça : http://chromattic.googlecode.com/svn...hromattic/apt/

Pour remplacer une resource existante, il est peut être possible de hacker javac mais ca reste du hack. Pour notre part quand on modifie une resource on charge dynamiquement une autre resource via un classloader custom.

courage

Ces exemples semblent modifier le code à l'exécution. Or si je suis mon idée de départ, il s'agit plutôt de compléter le code à la compilation : un @Delegate implique qu'un interface n'est pas entièrement implémentée, autrement dit, sans mécanisme de complétion à la compilation, ça ne pourra pas compiler.

Et je ne peux pas mettre ma classe incomplète abstract, sinon on ne pourra pas l'instancier.

L'autre solution serait de ne pas utiliser la classe incomplète, mais une implémentation générée et fournée par une factorie, mais ça complique le processus et ce n'est pas le but.

Donc a priori c'est :

soit APT+ANT
soit hack de javac

Pour le moment je ne vois pas d'autre solution.

**Alain Defrance** · 11/01/2011, 11h36

Non on génère une version d'une classe complétée basé sur ta classe de base puis au runtime on load la bonne classe, je vois pas où peut être le problème

On pourrait avoir une class abstraite et l'instancier si au classloading on load pas vraiment cette classe mais un typé dérivé qui est généré à la compilation.

**behess** · 11/01/2011, 12h21

Envoyé par Alain Defrance

Non on génère une version d'une classe complétée basé sur ta classe de base puis au runtime on load la bonne classe, je vois pas où peut être le problème

.

On pourrait avoir une class abstraite et l'instancier si au classloading on load pas vraiment cette classe mais un typé dérivé qui est généré à la compilation.

Alors là il faut m'expliquer parce que je ne pige rien.

Comment peut-on dire au chargement :

ClasseTiti.class c'est finalement ClasseToto.class (dérivant de ClasseTiti.class)

Et surtout comment, dans le source, tu peux faire un new ClasseTiti si elle est déclarée abstraite ? ça va clacher à la compilation !

**Alain Defrance** · 11/01/2011, 18h18

Envoyé par behess

Alors là il faut m'expliquer parce que je ne pige rien.

Comment peut-on dire au chargement :

ClasseTiti.class c'est finalement ClasseToto.class (dérivant de ClasseTiti.class)

Et surtout comment, dans le source, tu peux faire un new ClasseTiti si elle est déclarée abstraite ? ça va clacher à la compilation !

Si le classloader qui charge ClasseTiti.class return ClasseToto.class à la place, ça passera ...

**behess** · 11/01/2011, 18h38

Mais à la compilation quand je ferai :

ClasseTiti truc=new ClassTiti();

il ne risque pas de crier le compilateur (en admettant que ClasseTiti soit abstract) ?

**adiGuba** · 11/01/2011, 19h35

Envoyé par Alain Defrance

Si le classloader qui charge ClasseTiti.class return ClasseToto.class à la place, ça passera ...

Ce n'est pas si facile...

Déjà tout ceci ne peut pas être standard : une annotation ne peut pas modifier le bytecode généré par le compilateur.

Ce qu'il faudrait faire c'est "hacker" le compilateur afin de "rajouter" les méthodes au sein même de la classe. C'est possible et c'est ce que fait le projet Lombok (on en discute déjà ici) mais ca reste du hack et ce n'est pas 100% portable (sauf erreur c'est limité au compilateur officiel javac et au compilateur d'eclipse).

Je viens de voir que la prochaine version intégrera une annotation @Delegate...

Pour une solution standard c'est un peu plus complexe. Avec un Annotation Processor on ne peut pas modifier directement la classe courante. Une solution serait de passer par une classe abstraite et une convention de nommage pour la classe fille autogénéré (exemple AbstractMyObject génèrera une classe conforme MyObject)

Sinon il faudrait passer par un pre-compilateur... mais ca devient encore plus complexe !

a++

**Alain Defrance** · 11/01/2011, 20h18

Envoyé par adiGuba

Ce n'est pas si facile...
Pour une solution standard c'est un peu plus complexe. Avec un Annotation Processor on ne peut pas modifier directement la classe courante. Une solution serait de passer par une classe abstraite et une convention de nommage pour la classe fille autogénéré (exemple AbstractMyObject génèrera une classe conforme MyObject)

Nous ne nous sommes certainement mal compris, mais c'est ce que je suggère de faire

**behess** · 11/01/2011, 22h23

Encore une fois je reste persuadé que cela ne peut fonctionner que si on implémente une fabrique pour retourner un objet compatible avec AbstractMyObject, car impossible de faire directement new AbtractMyObject() !

Et une fabrique rajouterait certainement un niveau de complexité qui n'est pas forcément souhaité (ou souhaitable), même si c'est généralement une bonne façon de faire de la création d'objet.

**adiGuba** · 11/01/2011, 23h30

Tu n'as pas forcément besoin d'une fabrique.

Tu codes une classe "AbtractMyObject", exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
@Delegate
public abstact class AbtractMyObject implements List<String> {
 
    @Delegate
    protected final List<String> inner;
 
}

L'Annotation Processor crée implicitement une classe "MyObject" en implémentant les méthodes requises. En gros cela génèrerait une classe comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class MyObject extends AbstractMyObject {
 
    public String get(int index) {
        return super.inner.get(index);
    }
 
    // etc. pour toutes les méthodes non implémentées
 
}