Introspection en JAVA, présentation de l'API Reflection

Mes remerciements vont droit aux membres de la section Java pour leurs conseils et leurs remarques.

Le domaine d'application auquel on peut penser en premier est l'exécution. Même si on ne voit pas à première vue à quoi l'utilisation des métadonnées au cours de l'exécution peut servir, on peut naturellement convenir que si elles n'ont pas d'utilité à l'exécution l'intérêt de les stocker risque d'être fortement critiqué.

Prenons un exemple simple : vous disposez d'une bibliothèque (sous la forme d'un jar) et vous l'utilisez pour écrire un petit programme. Vous compilez et tout fonctionne correctement, jusqu'au jour où une nouvelle version de la bibliothèque devient disponible. Vous vous empressez de remplacer le jar et de relancer votre programme. Et là stupeur… votre programme ne fonctionne plus et vous obtenez un message équivalent au suivant :

Java.lang.NoSuchMethodError
    At MonProg.main(MonProg.java:36)

Vous comprenez très facilement qu'une méthode que vous utilisiez a dû disparaître de la bibliothèque. C'est justement grâce aux métadonnées que la machine virtuelle peut vous renvoyer avec précision le type d'erreur et la localiser.

Cette particularité permet donc un style de programmation dynamique permettant de faire abstraction du contenu de classes et d'écrire un code générique pouvant gérer n'importe quelle classe. Il n'est pas nécessaire de chercher très loin un tel programme… il suffit de regarder ce que proposent les environnements de développement en matière d'aide à la programmation ou de complétion de code. C'est également le cas pour d'autres langages me direz-vous. Et bien c'est beaucoup plus simple en Java, contrairement à ces autres langages pour lesquels les environnements de développement sont obligés de construire leur propre banque d'informations sur les métadonnées pour proposer ce service.

Pour obtenir des détails sur le format de métadonnées dans un binaire, vous pouvez vous reporter à des documents de spécification de la machine virtuelle Java.

Les noms des classes utilisés par la JVM sont différents de ceux utilisés par le développeur dans son fichier .java. En effet, la classe java.lang.String y sera gérée sous la forme java/lang/String. Pour des raisons de distinction d'un nom de classe au sein d'un flux, il peut arriver que la JVM rajoute les caractères 'L' et ';', on obtiendrait ainsi Ljava/lang/String;.

Les champs et méthodes sont identifiés par leur nom et les types sont codés de la manière suivante :

Pour ce qui est des méthodes, la JVM sait par exemple directement localiser la portion de byte code correspondant à l'implémentation d'une méthode à partir du nom et de la signature de cette dernière.

Il existe bien entendu un certain nombre d'utilitaires permettant d'ordonner et de rendre les informations disponibles dans le byte code compréhensibles par une personne.
L'un de ces outils, javap, est disponible dans le SDK et consiste en un décompilateur élémentaire. Il est présent dans le répertoire jdk\bin et sa syntaxe de base est la suivante :

javap NomClasse

où NomClasse correspond au nom de la classe (pas d'extension .java) précédée ou non du nom de paquetage. Ainsi, si on se place dans un répertoire classes contenant le paquetage monPaquetage, il faudra appeler :

javap monPaquetage.NomClasse

alors que si on se place directement dans le répertoire monPaquetage, il suffira d'utiliser la première syntaxe.

Nous pouvons par exemple regarder l'appel suivant sur java.lang.Object, lancé en ligne de commande :

E:\>javap java.lang.Object
Compiled from "Object.java"
public class java.lang.Object{
    public native int hashCode();
    static {};
    public java.lang.Object();
    protected void finalize();
       throws java/lang/Throwable
    public final native void notify();
    public final native void notifyAll();
    public final void wait();
       throws java/lang/InterruptedException
    public final native void wait(long);
       throws java/lang/InterruptedException
    public final void wait(long,int);
       throws java/lang/InterruptedException
    public final native java.lang.Class getClass();
    protected native java.lang.Object clone();
       throws java/lang/CloneNotSupportedException
    public boolean equals(java.lang.Object);
    public java.lang.String toString();
}

Mieux qu'un simple exemple, testez-le par vous-même. Vous aurez accès aux options de la commande par un classique :

javap -help

En effet, vous avez sans doute déjà rencontré cette classe à l'occasion d'un :

Class.forName(maClasse);

qui permet de récupérer un objet de type Class correspondant au nom passé en paramètre.

En fait, les instances de la classe Class peuvent être des classes ou des interfaces. Cette classe est indispensable pour pouvoir manipuler des métadonnées. Nous verrons que cette classe sera présente dans chaque exemple que nous rencontrerons, dont en voici un premier :

public class Exemple
{
   public Exemple()
   {
   }

   public String getNom(Object o)
   {
      Class c = o.getClass();
      return c.getName();
   }    
}

Dans cet exemple, la méthode getNom va renvoyer le nom de la classe de l'objet passé en paramètre.

Cette classe dispose des méthodes permettant d'extraire les informations sur une classe quelconque. En voici quelques-unes :

Venons-en à notre paquetage java.lang.reflect.
Nous avons vu qu'il était possible de récupérer des métadonnées sur les champs à partir d'une classe en appelant par exemple la méthode getField.
Partant d'un tel objet, nous pouvons consulter les informations à l'aide de méthodes de classe :

Nous avons vu précédemment qu'il était possible de connaître la visibilité d'un champ par l'intermédiaire de la méthode getModifier().
Il peut être surprenant de constater qu'il existe une classe Modifier alors que la méthode précédente renvoie un entier. Ce qu'il faut bien avoir à l'esprit pour comprendre ceci, c'est qu'il y a plusieurs informations à l'intérieur de cet entier, et il est nécessaire de faire appel à des méthodes de classe pour les distiller (néanmoins on conviendra qu'il pourrait être plus logique d'adapter la classe Modifier pour pouvoir faire renvoyer un objet plutôt qu'un entier).

Voici quelques-unes des méthodes utiles :

Ainsi, le code suivant permet de déterminer si le champ 'f' possède une visibilité publique :

if(java.lang.reflect.Modifier.isPublic(f.getModifier()))
{
   System.out.println("champ à visibilité publique");
}

Néanmoins, il existe une méthode assez pratique, à savoir String static toString(int mod), qui permet de récupérer une description classique complète des informations.

Pourquoi ne pas avoir géré les informations disponibles dans la classe Modifier directement dans la classe Field me direz-vous ? De telles informations sont justement également disponibles pour les méthodes et il est donc plus censé de les factoriser dans une classe spécifique.

Pour en revenir à nos méthodes, nous avons vu qu'il était possible de récupérer un objet décrivant une méthode, et nous allons voir ce qu'il est possible d'en extraire comme informations :

Enfin, dans le même esprit que pour la classe Method, on retrouve une classe Constructor qui permet de récupérer des informations sur un constructeur.

Le lecteur averti aura sans doute une question concernant la compatibilité entre la classe Class et les types primitifs de Java comme int, long, char…
Ces types n'étant pas des objets, comment se passe la compatibilité avec les méthodes que nous avons vues précédemment et qui renvoient des objets de type Class ? Et bien ce sont les types objet enveloppe correspondants (Integer, Long, Char…) qui seront renvoyés.
Même remarque lorsque nous tenterons d'appeler une méthode dynamiquement à l'aide de la réflexivité : il faudra passer comme paramètre un objet et non le type primitif qui est utilisé au niveau de la méthode, mais également caster le résultat renvoyé dans le type objet enveloppe correspondant (cela ne devrait plus être nécessaire avec Java 1.5).

Néanmoins, se pose alors une autre question. À savoir : comment distinguer deux méthodes entièrement identiques ne différant que par un type lequel est pour l'une un type primitif, et pour l'autre le type objet enveloppe correspondant ?
Prenons l'exemple du couple Integer/int : pour le premier ce sera Integer.class et pour le second Integer.TYPE. Ainsi, dans l'exemple suivant :

Class c = Class.forName("maClasse");
Class[] p1 = new Class[]{Integer.class, Integer.class);
Class[] p2 = new Class[]{Integer.TYPE, Integer.TYPE);
Method m1 = c.getMethod("somme",p1);
Method m2 = c.getMethod("somme",p2);

m1 correspond ici à la méthode somme(Integer, Integer) alors que m2 correspond à somme(int, int).

Imaginez le problème suivant : vous souhaitez pouvoir modifier la valeur du champ d'un objet de façon dynamique. Vous allez donc passer en paramètre le nom de ce champ sous la forme d'un String, mais vous ne pourrez pas agir sur ce champ avec les moyens classiques. Considérons donc une telle méthode :

void changeValeur(Object o, String nomChamp, Object val)

Il n'est bien entendu pas possible d'accéder au contenu du champ comme en programmation statique par :

o.nomChamp;

Nous sommes donc obligés de faire appel à la réflexivité.
Voici le code que nous allons par la suite commenter :

void changeValeur(Object o, String nomChamp, Object val) throws Exception
{
   Field f = o.getClass().getField(nomChamp);
   f.set(o,val);
}

Nous récupérons donc un objet de type Field correspondant au champ concerné par la modification, puis nous faisons appel à la méthode set sur ce champ qui permet de modifier le contenu du champ d'un objet (ici o) en lui attribuant la valeur passée en second paramètre.
La méthode set est la méthode la plus générale pour faire une affectation sur un objet, mais il existe des méthodes plus restreintes telles que setDouble(Object obj, double d) ou setBoolean(Object obj, boolean z).

Il y a bien entendu la possibilité d'utiliser des méthodes de consultation, ce qui permet d'écrire une méthode générique d'affichage du contenu d'un champ d'un objet :

void afficheValeur(Object o, String nomChamp) throws Exception
{
   Field f = o.getClass().getField(nomChamp);
   System.out.println(f.get(o));
}

Après avoir vu qu'il était possible d'agir sur les champs d'un objet à l'aide de la réflexivité, nous allons maintenant nous intéresser aux méthodes. Nous allons ainsi pouvoir lancer une méthode sur un objet de façon entièrement dynamique, en gérant bien entendu le passage des paramètres souhaités à la méthode.

Nous avons vu une certaine catégorie de méthodes pour la classe Method, à savoir ce qui concerne l'interrogation des métadonnées d'une méthode.
Comme nous avons vu comment récupérer la valeur d'un champ et la modifier, nous allons voir maintenant la méthode à utiliser pour lancer dynamiquement une méthode sur un objet ou une classe. La méthode en question est invoke dont voici la déclaration :

Object invoke(Object obj, Object[] args)

Dans le même esprit des exemples précédents, nous pouvons alors déclarer la méthode suivante :

Object lancerMethode(Object o, Object[] args, String nomMethode) throws Exception
{
  Class[] paramTypes = null;
  if(args != null)
  {
    paramTypes = new Class[args.length];
    for(int i=0;i<args.length;++i)
    {
      paramTypes[i] = args[i].getClass();
    }
  }
  Method m = o.getClass().getMethod(nomMethode,paramTypes);
  return m.invoke(o,args);
}

Cette méthode permet donc de lancer une méthode sur un objet, et éventuellement de récupérer un résultat, et ceci en récupérant la liste des paramètres et le nom de la méthode. Attention cependant : comme cela a été dit précédemment, la recherche de la méthode par getMethod va examiner les types des paramètres et il est donc indispensable de ne pas se tromper au niveau des paramètres. De plus, cela pose quelques problèmes pour les méthodes génériques ayant pour paramètre le type Object, mais qu'on désire appeler avec un paramètre d'un type dérivé. En effet, getMethod cherchera la méthode dont le paramètre a pour type le type dérivé en question, et comme il ne le trouvera pas il renverra une exception.
Je vous laisse chercher une solution à ce problème…

Dans le cas d'une méthode de classe, le paramètre obj de la méthode invoke ne sera pas pris en compte. Vous pouvez tout aussi bien mettre null que n'importe quel objet.

Nous avons vu notamment au niveau de la classe Class qu'il était possible de récupérer un champ ou une méthode à l'aide de getFields ou de getMethods. Nous étions alors capables de récupérer les champs et méthodes publics.
Vous aurez sans doute remarqué la présence de méthodes semblables appelées getDeclaredFields et getDeclaredMethods au niveau de la documentation. C'est grâce à ces méthodes que nous allons pouvoir transgresser une première fois les règles de l'encapsulation en étant capable de consulter les caractéristiques des champs et méthodes protégés et privés.

Quelles sont les raisons pour lesquelles de telles fonctionnalités sont disponibles dans l'API Reflection ? L'origine du besoin se situe toujours au niveau de la machine virtuelle qui se doit de pouvoir explorer tous les éléments d'une classe, mais surtout la nécessité de disposer des métadonnées pour pouvoir détecter les erreurs en cours d'exécution.

Encore pire…
Nous allons transgresser une seconde fois, mais cette fois-ci avec des conséquences bien plus graves, en supprimant les verrous en lecture/écriture des éléments protégés et privés.
En effet, même si vous avez pu récupérer les informations sur un champ privé, vous ne serez capables ni de lire ni de modifier le contenu de ce champ (déclenchement de IllegalAccessException).
Néanmoins, il existe pour les différents éléments (Field, Method, Constructor) la méthode setAccessible(boolean b) qui permet justement de faire sauter le verrou de sécurité. Grâce à cette méthode, il est maintenant très aisé de consulter l'ensemble des champs pour une classe donnée. Mais il est désormais surtout possible de modifier la valeur d'un champ et de lancer une méthode privée.

Prenons une classe Secret avec un champ privé priv (String).
L'exemple suivant va modifier ce champ privé :

void modifierChamp(Secret s, String val)
{
   Field f = s.getClass().getDeclaredField("priv");
   f.setAccessible(true);
   f.set(s,val);
}

Il existe néanmoins des possibilités pour combler ce manque de protection.
En effet, la méthode setAccessible est définie dans la classe AccessibleObject (dont dérivent notamment les classes Field, Method et Constructor). Il est alors possible de définir qui possède le droit d'appeler la méthode setAccessible en définissant un SecurityManager.
Ceci dépassant le cadre de cet article, je vous laisse rechercher davantage d'informations en consultant le paquetage java.security.