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

Version imprimable

05/01/2011, 12h29
behess

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

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 !
06/01/2011, 17h26
behess

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.
06/01/2011, 18h08
kimjoa

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
06/01/2011, 18h24
professeur shadoko

note: on n'utilise plus vraiment APT on passe des AnnotationProcessor au compilateur. voir doc ...
06/01/2011, 19h29
Alain Defrance

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 :ccool:
07/01/2011, 10h05
behess

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).
07/01/2011, 11h13
Alain Defrance

Citation:

Envoyé par behess

j'apprends plein de trucs en ce moment

Je te souhaite de ne jamais arreter :mrgreen:
07/01/2011, 23h51
behess

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 :ccool:

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 ?
09/01/2011, 01h36
behess

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 :P
11/01/2011, 09h19
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 ;)
11/01/2011, 09h22
Alain Defrance

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) :)
11/01/2011, 10h47
behess
Citation:

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.
11/01/2011, 11h36
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.
11/01/2011, 12h21
behess

Citation:

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 !
11/01/2011, 18h18
Alain Defrance

Citation:

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 ...
11/01/2011, 18h38
behess

Mais à la compilation quand je ferai :

ClasseTiti truc=new ClassTiti();

il ne risque pas de crier le compilateur (en admettant que ClasseTiti soit abstract) ?
11/01/2011, 19h35
adiGuba

Citation:

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++
11/01/2011, 20h18
Alain Defrance

Citation:

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 8-)
11/01/2011, 22h23
behess

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.

Tu n'as pas forcément besoin d'une fabrique.
Tu codes une classe "AbtractMyObject", exemple :
Code:

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:

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 }
Enfin dans ton code tu utilises directement MyObject...
Maintenant la génération de code ne doit pas être très évidente, mais ce doit être faisable...

a++

Attends, mais tu sais que c'est pas con en fait ;)

J'étais resté sur le fait de faire appel à mon type déléguant, mais si je pointe directement sur un type déléguateur, ça le fait (sauf dans l'IDE où il va sans cesse me proposer de créer ma classe et où je n'aurais pas de complétion sur les constructeurs puisque inexistants) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 [...] WithDelegation_MaClasse toto=new MaClasse(); // là l'IDE gueule et pas de complétion pour le constructeur (inconnu alors) [...] [...] abstract class WithDelegation_MaClasse extends Bidule implements InterfaceMachin, InterfaceTruc { @Delegate protected InterfaceMachin fieldMachin; @Delegate protected InterfaceTruc fieldTruc; WithDelegation_MaClasse(InterfaceMachin p_machin, InterfaceTruc p_truc){ fieldMachin=p_machin; fieldTruc=p_truc; } [...] } [...] @GeneratedDelegateClass class MaClass extends WithDelegation_MaClasse { //méthodes déléguées //réplication des constructeurs avec appel à super(...); }
Du coup j'ai juste à imposer une syntaxe, vérifier les cas litigieux et à utiliser un Filer :)

Merci maître adiGuba, toi au moins tu sais expliquer les choses !

Reste plus qu'à voir si ça marche (le plus dur sera de savoir si une méthode est implémentée dans MaClasse, Bidule, ou un autre parent).

Remarque : pour le problème de l'éditeur je devrais sans doute conserver la syntaxe

Code:

WithDelegate_MaClass toto=new WithDelegate_MaClass(...)

qui serait remplacé à la volée par

Code:

MaClass toto=new MaClass(...)

mais c'est encore super complexe...

Edit : non en fait ça ne change rien car en mettant la classe déléguante abstract j'ai un autre message d'erreur puisque ma classe est abstraite... donc finalement il me faudra supporter les erreurs de classe introuvable par l'IDE et l'absence de complétion ; avec des classes incomplètes (mon idée initiale) j'aurais eu d'autres messages d'erreur, le moindre mal est sûrement celui que tu proposes.

Pour l'IDE j'utilise IntelliJ qui permet de configurer un processing d'annotation et ainsi te faire de la completion sur les types générés, mais j'imagine que c'est une feature répandue.

Si tu veux rendre complètement opaque la génération de code et éviter de te trimballer 2 types tu peux tenter un truc du genre :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 public class DelegateClassLoader extends ClassLoader { @Override public Class<?> loadClass(String name) throws ClassNotFoundException { Class<?> clazz = super.loadClass(name); if (clazz.isAnnotationPresent(Delegate.class)) { clazz = super.loadClass("WithDelegate_" + name); } return clazz; } }
C'est du sucre mais ca rend plus sexy l'utilisation de tes types générés.

Merci Alain pour cette suggestion.

Tu sembles vouloir dire que c'est la classe déléguante (WithDelegation_MaClasse) qui serait chargée si j'écris :

Code:

WithDelegate_MaClasse toto=new MaClasse(...);

Cependant c'est bien la classe déléguatrice que je veux, pas la classe déléguante...

Je ne comprends donc pas à quoi ça peut servir et comment s'en servir :P un exemple serait le bien venu ;)

A la limite, je comprendrai mieux de pouvoir écrire :

Code:

WithDelegate_MaClasse toto=new WithDelegate_MaClasse(...);

Et que ça me charge la classe délégatrice...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 public class DelegatorClassLoader extends ClassLoader { @Override public Class<?> loadClass(String name) throws ClassNotFoundException { Class<?> clazz = super.loadClass(name); if (clazz.isAnnotationPresent(Delegate.class) && name.startWith("WithDelegate_")) { clazz = super.loadClass(name.substring("WithDelegate_".length+1); } return clazz; } }
ou un truc comme ça :P

J'aurai toujours les warning sur le fait que c'est une classe abstraite, mais peut-être que c'est plus sympa à utiliser.

Par contre je ne sais pas comment utiliser ce ClassLoader...

12/01/2011, 10h52
professeur shadoko

sauf erreur ou omission de ma part: si tu charges la classe englobante qui fait de la délégation la classe sur laquelle la délégation opère sera chargée .... donc je ne vois pas l'intérêt de ta version de code.

En fait je crois que j'ai compris... tu as une logique inverse de la mienne ; elle est sûrement mieux d'ailleur : je pourrais écrire :

Code:

MaClasse toto=new MaClasse(...);

avec :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public abstract class MaClasse implements List {
 
    @Delegate protected List machin;
 
    public MaClasse(List p_machin){
        this.machin=p_machin;
    }
 
}
 
@GeneratedDelegateClass
public class DelegatorMaClasse extends MaClasse {
 
    public MaClasse(List p_machin){
        super(p_machin)
    }
 
    @Override
    public boolean Add(Object p_element){
       machin.Add(p_element);
    }
 
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class DelegatorClassLoader extends ClassLoader
{
   @Override
   public Class<?> loadClass(String name) throws ClassNotFoundException
   {
      Class<?> clazz = super.loadClass(name);
      if (clazz.isAnnotationPresent(Delegate.class))
      {
         clazz = super.loadClass("Delegator"+name);
      }
      return clazz;
   }
}

Comment je peux rendre l'instantiation du ClassLoader transparente ?

12/01/2011, 10h54
behess

Citation:

Envoyé par professeur shadoko

sauf erreur ou omission de ma part: si tu charges la classe englobante qui fait de la délégation la classe sur laquelle la délégation opère sera chargée .... donc je ne vois pas l'intérêt de ta version de code.

Je veux bien mais comprends rien... tu peux expliciter s'il te plait ?
12/01/2011, 10h56
behess

Citation:

Envoyé par Alain Defrance

Pour l'IDE j'utilise IntelliJ qui permet de configurer un processing d'annotation et ainsi te faire de la completion sur les types générés, mais j'imagine que c'est une feature répandue.

j'utilise aussi IntelliJ, c'est quoi cette fonctionnalité ?
12/01/2011, 11h19
Alain Defrance

Tiens une doc IntelliJ/JPA qui fait ça : http://blogs.jetbrains.com/idea/2009...-20-metamodel/

Pour le classloader soit tu l'appel soit, soit tu peux le définir comme classloader system.
Je te conseil de lire ça : http://download.oracle.com/javase/1....assLoader.html. Tu as une propriété system.class.loader qui t'aidera :ccool:
12/01/2011, 12h01
behess

En fait le classloader ne fonctionne qu'à l'exécution...

Si je mets MonDeleguant abstract et
si je fais un "new MonDeleguant(...)",
à la compilation il me dira "MonDeleguant ne peut pas être instancié".

Si je mets MonDeleguant concret et
si je fais un "new MonDeleguant(...)",
à la compilation il me dira "MonDeleguant n'implemente pas complètement les interfaces".

Si je mets MonDeleguant abstract et
si je fais un "new DelegatorMonDeleguant(...)",
lors de l'édition il me dira "DelegatorMonDeleguant n'existe pas".

Donc finalement, j'aurai quoi qu'il arrive une erreur et je ne peux pas me débarrasser des problèmes de compilation sans faire appel uniquement à la classe générée :(
12/01/2011, 12h04
behess

Citation:

Envoyé par Alain Defrance

Tiens une doc IntelliJ/JPA qui fait ça : http://blogs.jetbrains.com/idea/2009...-20-metamodel/

Pour le classloader soit tu l'appel soit, soit tu peux le définir comme classloader system.
Je te conseil de lire ça : http://download.oracle.com/javase/1....assLoader.html. Tu as une propriété system.class.loader qui t'aidera :ccool:

merci pour la doc ! je vais lire ça :)
12/01/2011, 14h23
behess

Finalement, j'ai l'impression qu'il est impossible de faire de la delegation propre par les annotations.

Mais ce fut une belle aventure et j'ai appris plein de trucs sympa qui pourront toujours me resservir...

Merci pour votre participation :ccool:
12/01/2011, 18h04
Alain Defrance

Tout est possible.

J'ai eu un peu le temps aujourd'hui en fin de journée. Je t'ai écrit le coeur du problème : https://github.com/defrancea/delegationdemo--dvp-

Il te reste quand même un TODO : la génération du fichier (qui actuellement est écrit) mais le méchanisme autours de ça est en place.

EDIT : Bien entendu c'est pas une véritable implémentation c'est juste un petit bout de code pour te montrer comment je vois les choses.

Alain.
12/01/2011, 23h59
behess

c'est bien ce que j'avais compris (et que j'ai aussi implémenté en ce sens sur la base de tes conseils) je me permets juste quelques remarques sur ton implémentation (mais tu as fait ça vite fait) :
- j'avais supposé une délégation d'interface, mais ton approche est intéressante
- d'où sort ce new B() ? dans l'idéal le délègué est passé par constructeur
- tu n'as qu'un constructeur par défaut ; quid d'un vrai constructeur avec ta factory ?
- être obligé de passer par une factory, en mode classe utilitaire en plus, c'est pas userfriendly. c'est déjà pas si mal, mais ça ne me plait pas trop

La conclusion disait simplement que faire une delegate userfriendly c'est pas possible : on peut toujours faire du delegate avec annotations mais c'est trop gras pour être assez pratique. Mais ça reste intéressant ! La je n'ai plus le temps d'approfondir, mais si tu arrives a quelque chose de finalisé, tiens moi au courant, sinon je me repencherai dessus dans quelques temps.

Edit: un truc me chiffonne en fait : si je veux étendre A (hors délégation), comment je fais ?
13/01/2011, 08h09
Alain Defrance
Salut,

Citation:

Envoyé par behess

c'est bien ce que j'avais compris (et que j'ai aussi implémenté en ce sens sur la base de tes conseils) je me permets juste quelques remarques sur ton implémentation (mais tu as fait ça vite fait) :

En effet.

Citation:

Envoyé par behess

- j'avais supposé une délégation d'interface, mais ton approche est intéressante

Peu importe, ça marcherait pareil.

Citation:

Envoyé par behess

- d'où sort ce new B() ? dans l'idéal le délègué est passé par constructeur

Dans l'idéal ca pourrait interessant de n'avoir pas d'instance et d'injecter le délégué et/ou le passer par constructeur mais peut importe cela ne changerai rien.

Citation:

Envoyé par behess

- tu n'as qu'un constructeur par défaut ; quid d'un vrai constructeur avec ta factory ?

C'est quoi le problème ? On pourrait compier les constructeurs vers le délégué, on peut également invoquer un constructeur ayant des paramètres avec de la reflexion.

Citation:

Envoyé par behess

- être obligé de passer par une factory, en mode classe utilitaire en plus, c'est pas userfriendly. c'est déjà pas si mal, mais ça ne me plait pas trop

On pourrait se passer de la factory en overridant le classloader system il me semble (j'ai eu à le faire). Sinon si tu préfère tu peux toujours avoir :

Code:

A a = new A_WithDelegation();

Pour ma part je n'aime pas rendre visible des types qui ne sont pas présent avant la compilation, et mon code ne pose pas de problèmes de completion même sans configuration de processor au niveau de l'IDE.

Citation:

Envoyé par behess

La conclusion disait simplement que faire une delegate userfriendly c'est pas possible : on peut toujours faire du delegate avec annotations mais c'est trop gras pour être assez pratique. Mais ça reste intéressant ! La je n'ai plus le temps d'approfondir, mais si tu arrives a quelque chose de finalisé, tiens moi au courant, sinon je me repencherai dessus dans quelques temps.

J'ai pris le temps d'écrire ca très rapidement hier soir, tu te doutes bien que j'ai du travail et que je ne peux pas m'occuper de "de faire un code source full ok, productisé & co".
Si ca t'interesse de polir/améliorer c'est à toi de jouer :ccool:

Citation:

Envoyé par behess

Edit: un truc me chiffonne en fait : si je veux étendre A (hors délégation), comment je fais ?
Code:

1 2 A2 extends A A_WithDelegation extends A2
Rien ne t'empêche de déterminer la première classe de ta hiérarchie qui délègue et la dernière.
Rien ne t'empêche non plus de créer une annotation facultative sur un type qui permet de customiser ce comportement.

Comme tu le vois (ou tu le sait), développer de la lib/framework est compliqué car ton utilisateur est un développeur et il sera tenté de faire n'importe quoi, il faut donc penser à tout et prévoir le plus de cas possible pour pas que ca chie/bride le développeur.
Néanmoins c'est le jeu et il faut avancer petit à petit et régler les problèmes les uns derrières les autres à base de test unitaire pour éviter les régressions.
Je n'ai pas vu de truc "bloquant" dans ce que tu m'a dit, le sucre que tu veux poser par dessus ou les features/use case que tu m'a donné plus haut ne sont que des implémentations supplémentaires.
Courage :)