J2SE 1.5 Tiger

Le langage Java s'appuie sur des types primitifs pour décrire les types de base. Il s'agit essentiellement des types représentant des chiffres (byte, short, int, long, double et float), des booléens (boolean) et des caractères (char).
Cependant, en Java, tout se doit d'être « objet ».

Ainsi, un code comme celui qui suit lève une erreur de compilation avec J2SE 1.4:

List list = new ArrayList();
int myInt = 100;
list.add(myInt); //erreur de compilation ici (java.lang.ClassCastException)

Pour résoudre cette erreur; il faut encapsuler l'entier dans une classe référence (wrapper) comme la classe Integer :

list.add(new Integer(myInt)) ;

Ce type de transformation (aussi appelé boxing) peut rapidement s'avérer pénible. D'autant que le processus inverse (appelé unboxing) est nécessaire pour retrouver son type initial. Avec Tiger, cette conversion explicite devient obsolète. En effet, Tiger introduit l'autoboxing qui convertit de manière transparente les types de base en références.

La table de conversion qui suit donne les correspondances entre type de base et wrapper (enrobeur) :

On peut ainsi écrire directement :

List list = new ArrayList();
int myInt = 100;
list.add(myInt);

Le compilateur se chargera de transtyper automatiquement la variable dans son type enrobé.

En java, une tâche récurrente et fastidieuse est l'itération sur une collection (au sens large c'est-à-dire autant sur un objet Collection que sur un tableau).

En effet, pour parcourir une collection, il faut instancier un itérateur sur celle-ci et pour chaque itération récupérer l'élément dans un objet conteneur. De plus, chaque élément doit être transtypé dans son type d'origine pour être utilisé en tant que tel.

L'expression actuelle du for est assez puissante et peut être utilisée afin de parcourir des collections ou des tableaux. Cependant, elle n'est pas optimisée pour une simple itération, car l'itérateur ne sert qu'à obtenir les éléments.

List stringList = new ArrayList();
stringList.add("foo");
stringList.add("bar");
...
for(Iterator it = stringList.iterator(); it.hasNext(); )
{
  String currentString = (String)it.next();
  // Do something with the string...
}

Tiger introduit une manière supplémentaire d'utiliser le mot clé for, qui s'avère être beaucoup plus légère et facile à mettre en œuvre.

Sa syntaxe est la suivante :

for(FormalParameter : Expression) Statement

Expression doit être un tableau ou une instance de la nouvelle interface java.lang.Iterable. L'interface java.util.Collection étend donc maintenant Iterable.

Avec cette nouvelle manière d'utiliser le for, nul besoin d'instancier explicitement un itérateur sur la collection.

De plus, le type des éléments contenus dans la collection est défini dans le corps de la boucle, évitant ainsi le recours au transtypage explicite.

for(String currentString: stringlist)
{
  // Do something with the string...
}

On le voit, cette nouvelle forme simplifie le développement et améliore la lisibilité des programmes.

Il existe cependant une limitation à celle-ci, il n'est pas possible de l'utiliser lorsque l'on souhaite modifier la collection, puisqu’aucun itérateur n'est accessible.

On peut aussi déplorer l'utilisation d'un mot clé ayant déjà une utilisation propre. Sun rétorque à cela que l'introduction d'un nouveau mot clé (foreach ?) est très (trop ?) coûteuse.

Un type énuméré est un type dont la valeur fait partie d'un jeu de constantes définies. Jusqu'ici, le type enum du C avait été omis en Java.

Une façon simple de créer un type énuméré est de définir une classe ne contenant que des constantes de type int :

public class Numbers
{
  public static final int ZERO = 0;
  public static final int ONE = 1;
  public static final int TWO = 2;
  public static final int THREE = 3;
  ...
}

Cependant, celle-ci comporte plusieurs désavantages.

• Elle n'est pas « type-safe », c'est-à-dire qu'elle n'empêche pas d'affecter une valeur inconnue à la variable de type int, entraînant des erreurs à l'exécution, qui ne sont donc pas levées à la compilation.
• Pour ajouter une valeur possible au type, il faut éditer la classe et tout recompiler.
• L'utilisation de ces constantes est souvent préfixée par le nom du type, sans pour autant posséder d'espace de nommage propre au sein du programme.
• Elle ne fournit pas de correspondance entre la valeur de la constante et sa description (comme il est d'usage de le faire pour une collection d'exceptions par exemple).
• D'un point de vue purement objet, ce n'est pas une classe, car un des paradigmes objet définit une classe comme un ensemble qui encapsule des données et des méthodes permettant de traiter ou manipuler celles-ci. Ici, il n'y a pas de méthodes.

Un type énuméré « type-safe » est un type énuméré qui provoque des erreurs de compilation si l'on tente de lui affecter des valeurs non permises. Il existe bien entendu des patterns permettant de créer ces types énumérés, qui de plus contiennent des méthodes de traitement et leur associent des descriptions.

Le J2SE 1.5 fournit lui un type énuméré « type-safe » en standard via le mot clé enum:

public enum Numbers {ONE, TWO, THREE, ...};

Pour chaque type décrit dans l'énumération, une classe complète (valeur et méthodes utilitaires) est générée (à la différence des énumérations en C/C++ qui ne sont que des entiers).

De plus une classe supplémentaire est générée (Numbers.class ici), qui implémente l'interface Comparable et Serializable, qui contient des variables statiques correspondant aux valeurs, et qui définit ou redéfinit un certain nombre de méthodes ( values(), toString(), valueOf(String s) , hashCode(), compareTo()…).

Ainsi, nous utilisons les énumérations Java de la manière suivante :

Numbers num = Numbers.ONE;

Au lieu de :

int num = Numbers.ONE;

Cette construction présente les avantages suivants.

• Elle est « type-safe ».
• Elle fournit un espace de nommage pour chaque énumération, évitant le recours à l'utilisation d'un préfixe dans les noms des constantes.
• Étant des objets à part entière, chaque constante peut changer son implémentation sans obliger à changer le code source des classes qui l'utilisent et donc, sans obliger à recompiler.
• Les valeurs, au lieu d'être de simples nombres, peuvent être des messages explicites.

De plus, le mot clé enum remplaçant le mot clé class, nous pouvons imaginer tout type de constructeur, permettant ainsi de créer des énumérations complexes :

public enum Numbers
{
  ONE("première occurrence ", 1),
  TWO("deuxième occurrence ", 2),
  THREE("troisième occurrence ", 3);
  
  Numbers(String description, int value)
  {
    this.description = description;
    this.value = value;
  }
  
  private string description;
  private int value;
  
  public String getDescription()
  {
    return this.description;
  }
  
  public int getValue()
  {
    return this.value;
  }
}

Quel développeur n'a pas été un jour confronté au problème du traitement d'un nombre variable de paramètres ?

Ce problème récurrent, bien que facilement contournable par le passage en paramètre d'un tableau de données dans les signatures des méthodes, nous oblige à spécialiser celles-ci. Ce qui n'est pas sans enlever une certaine généricité ou oblige à utiliser le polymorphisme, tout en compliquant les interfaces.

Par exemple :

void doSomething(Object[] args)
{
  // do something
}

// invoke the method
doSomething(new Object[]{"arg1", "arg2", "arg3"});

Tiger introduit l'ellipse « … » pour remédier à cela. Il s'agit d'un opérateur qui informe le compilateur que le nombre d'arguments peut être variable.

La précédente signature devient alors :

void doSomething(Object… args)
{
  // do something
}

// invoke the method
doSomething("arg1", "arg2", "arg3");

// invoke the method in an other way
doSomething("arg1", "arg2);

Cette notation, en plus d'apporter de la généricité, permet d'alléger légèrement le travail du développeur.

Attention : l'ellipse de Tiger ne s'utilise pas de la même manière que l'ellipse du C++.
En effet, l'ellipse du C++ prévoit que l'on peut passer n'importe quel type d'argument dans la signature. En Java, le type précédant directement l'ellipse définit le type des arguments susceptibles d'être ajoutés.

Nous allons en montrer un exemple concret dans le chapitre suivant qui concerne la nouvelle méthode de sortie standard formatée: le très connu printf(…).

Tiger introduit une nouvelle méthode permettant de produire des messages formatés sur la sortie standard. Celle-ci vient en complément de l'actuelle méthode System.out.print().

Cette méthode s'appuie directement sur le mécanisme d'ellipse vu précédemment et fonctionne comme la très connue fonction printf(…) en C.

Avec l'actuelle méthode println(), nous avons :

double a = 5.6d ;
double b = 2d ;
double mult = a * b ;

System.out.println(a + " mult by " + b + " equals " + mult);

Avec le nouveau printf(…), nous aurons :

double a = 5.6d ;
double b = 2d ;
double mult = a * b ;

System.out.printf("%lf mult by %lf equals %lf \n", a, b , mult);

Les deux méthodes produisent le même message sur la sortie standard :

> 5.6 mult by 2 equals 11.2

Mais ce n'est pas tout. Cette nouvelle méthode permet bien plus, comme des formatages avancés :

double a = 5.6d ;
double b = 2d ;
double mult = a * b ;

System.out.printf("%3.2lf mult by %3.2lf equals %3.2lf\n", a, b , mult);

Le message standard sera dans ce cas :

> 005.60 mult by 002.00 equals 011.20

L'API Scanner fournit des fonctionnalités de base pour lire tous les flux standards.
Cette classe peut être utilisée pour convertir du texte en primitives ou en Strings.
De plus, étant donné qu'elle est basée sur le package java.util.regex, elle offre un moyen simple d'appliquer des expressions régulières sur des flux, des fichiers de données, des Strings, ou tout autre objet implémentant la nouvelle interface Readable.

Par exemple, pour lire l'entrée standard, il suffit d'invoquer la méthode next() du Scanner :

Scanner scanner = Scanner.create(System.in);

try
{
  String s1 = scanner.next(Pattern.compile("[Yy]"));
  // only match Y or y
}
catch(InputMismatchException e)
{
  System.out.println("Expected Y or y");
}

scanner.close();

Ce bout de code simple permet de capter toutes les frappes de Y ou y sur le clavier si celui-ci est l'entrée standard.

Il est à noter que la méthode next() est bloquante si aucune donnée n'est disponible dans le flux.

Le Scanner peut aussi être utilisé à la place du classique StringTokenizer. Il peut utiliser tous types de délimiteurs grâce à l'adjonction des expressions régulières :

String input = "1 test 2 test red test blue test";

Scanner s = Scanner.create(input).useDelimiter("\\s*test\\s*");

System.out.println(s.nextInt());
System.out.println(s.nextInt());
System.out.println(s.next());
System.out.println(s.next());

s.close();

Ces instructions produisent la sortie suivante:

>1
>2
>red
>blue

Quiconque a déjà utilisé les StringTokenizer pour découper ou parser un fichier se rend tout de suite compte de la puissance du Scanner.

Toujours dans leur volonté de simplifier les codes source écrits en Java, les personnes en charge des spécifications de Tiger ont retenu celle des imports statiques.

La proposition vise à introduire une variante de l'import pour rendre visibles des méthodes et des variables statiques de la même manière que l'on importe des classes ou des interfaces.
Cette fonctionnalité permet de passer outre l'antipattern de l'interface constante (voir Effective Java de Joshua Bloch, le lead manager de Tiger).

La forme retenue pour la déclaration d'un tel import est la suivante :

import static TypeName . Identifier ;
import static TypeName . * ;

Son but principal, outre simplifier le code source, est de pallier le problème de l'espace de nommage déjà évoqué dans le chapitre sur les types énumérés (préfixage obligatoire) et de permettre d'ajouter des constantes et méthodes de portée globale (quasiment l'équivalent des #define en C, avec des différences tout de même).

Jusqu'ici la seule façon de faire était de les définir en tant qu'attributs statiques d'une classe conteneur, et de faire ensuite explicitement référence à cette classe en utilisant le nom de ce conteneur comme espace de nommage.

L'exemple typique est la classe Math de l'API standard dans laquelle toutes les méthodes et tous les attributs sont statiques:

Math.PI ;
Math.sin(x) ;
Math.cos(x) ;
...

Tiger assouplit l'utilisation de ces classes en autorisant les imports statiques. Cela permet de traiter les membres des classes statiques en tant que classes globales (pour le fichier courant) de la même manière que nous le faisons pour les classes classiques.

La conséquence directe est la suppression des préfixes obligatoires lorsque l'on fait référence aux membres statiques.

On peut ainsi écrire :

import static java.lang.Math.PI ;
import static java.lang.Math.sin();
// ou pour importer toutes les références statiques
import static java.lang.Math.* ;
...
PI ; // fait référence à Math.PI
...
sin(x) ; // fait référence à Math.sin()
cos(x) ; // fait référence à Math.cos()
...

Un bémol est toutefois à apporter à cette amélioration.

Si nous utilisons cette facilité sans prendre garde, nous pouvons arriver à des situations de conflits d'espaces de nommage. C'est pourquoi je recommande de ne pas utiliser cette fonctionnalité qui n'apporte pas de révolution et qui est sujette à introduire des erreurs (régressions en cas de reprise d'un code préexistant).

D'autant plus que les éditeurs actuels savent très bien gérer cela.

Les imports statiques ne devraient être utilisés que pour des petites classes où il n'y a pas de conflit d'espace de nommage.

La plateforme Java fournit des primitives basiques et de bas niveau pour écrire des programmes concurrents et synchronisés, mais celles-ci sont difficiles à utiliser correctement.
La plupart des programmes deviennent plus clairs, plus rapides, plus faciles à écrire et plus fiables si une synchronisation de haut niveau est utilisée.

Une librairie étendue d'utilitaires de gestion de la concurrence a été intégrée dans le J2SE 1.5.

Cette API, connue comme le package java.util.concurrent, contient des pools de threads, des queues, des collections synchronisées, des verrous spéciaux (atomiques ou pas), des barrières (ou barrage), et bon nombre d'autres utilitaires, comme un framework d'exécution de tâches. L'ajout à la plateforme Java de cette librairie est un apport substantiel qui va bouleverser la façon dont nous écrivons la gestion de la concurrence dans les applications Java.

En fait cette API n'est autre que celle développée par Doug Léa, professeur au State University of New York (SUNY) College d'Oswego et qui est devenue le JSR-166 (anciennement dans le package edu.oswego.cs.dl.util.concurrent).

Nous allons voir par la suite une vue rapide des principaux éléments de cette énorme librairie.

Les exécuteurs de tâches.▲

Executor executor = anExecutor;
...
executor.execute(new RunnableTask1());
executor.execute(new RunnableTask2());
...

class NetworkService
{
  private final ServerSocket serverSocket;
  private final ExecutorService pool;
  
  public NetworkService(int port, int poolSize) throws IOException
  {
    serverSocket = new ServerSocket(port);
    pool = Executors.newFixedThreadPool(poolSize);
  }
  
  public void serve()
  {
    try
    {
      for (;;)
      {
        pool.execute(new Handler(serverSocket.accept()));
      }
    }
    catch (IOException ex)
    {
      pool.shutdown();
    }
  }
}

class Handler implements Runnable
{
  private final Socket socket;
  
  Handler(Socket socket)
  { 
    this.socket = socket; 
  }
  
  public void run()
  {
    // read and service request
  }
}

Les queues▲

public boolean offer(Object element)
public Object remove()
public Object poll()
public Object element()
public Object peek()

Les Map atomiques▲

La représentation du temps et de ses unités: TimeUnit▲

Lock lock = ...; // création d'un lock
...
if ( lock.tryLock(50L, TimeUnit.MILLISECONDS) ) 
...

Les synchroniseurs (loquet, barrière, sémaphore et échangeur)▲

class RequestProcessor
{
  // ...
  
  void main() throws InterruptedException
  {
    CountDownLatch latcher = new CountDownLatch(N);
    Executor e = ... ;
    
    for (int i = 0; i < N; ++i)
    {
      // create and start threads
      e.execute(new RequestRunnable(latcher, i));
      
      latcher.await(); // wait for all to finish
    }
  }
}

class RequestRunnable implements Runnable
{
  private final CountDownLatch localLatcher;
  private final int id;
  
  RequestRunnable(CountDownLatch latcher, int id)
  {
    this.localLatcher = latcher;
    this.id = id;
  }
  
  public void run()
  {
    try
    {
      doRequest(id);
      localLatcher.countDown();
    }
    catch (InterruptedException ex) {..};
  }
  
  void doRequest () { ... }
}

private Semaphore s = new Semaphore(1, true);

s.acquireUninterruptibly(); // bloquant
value = balance +1; // section critique exclusive
s.release();

class Resources
{
  private static final RES_NUMBER = 10;
  private final Semaphore token = new Semaphore(RES_NUMBER, true);
  private List resourcesPool = new ArraylList(RES_NUMBER);
  
  public Object getResource()
      throws InterruptedException
  {
    token.acquire();
    return resourcesPool.get();
  }
  
  public void releaseResource(Object o)
  {
    resourcesPool.put(o);
    token.release();
  }
}

class SandGlass
{
  Exchanger<Data> exchanger = new Exchanger();
  
  class SandGlassLowRoom implements Runnable
  {  
    public void run()
    {
      Data content = computeContent();
      
      try
      {
        content = exchanger.exchange(content);
      }
      catch (InterruptedException ex){}
    }
  }
  
  class SandGlassHighRoom implements Runnable
  {
    public void run()
    {
      Data content = computeContent();
      
      try
      {
        content = exchanger.exchange(content);
      }
      catch (InterruptedException ex){}
    }
  }
  
  void openRooms()
  {
    new Thread(new SandGlassLowRoom()).start();
    new Thread(new SandGlassHighRoom()).start();
  }
}

Les traitements asynchrones anticipés▲

class ReportBuilder
{
  Future<ResultSet> result = null;
  SQLService sqlService = …; // un framework de requétage
  
  void build(String reportStatement)
       throws InterruptedException
  {
    result = executor.submit
    (
      new Callable<String>()
      {
        public String call()
        {
          return sqlService.query(reportStatement) ;
        }
      }
    )
  }
}

Les variables atomiques▲

Les nouveaux verrous « haute performance »▲

class BoundedBuffer
{
  Lock lock = new ReentrantLock();
  final Condition notFull = lock.newCondition();
  final Condition notEmpty = lock.newCondition();
  
  Object[] items = new Object[100];
  int putptr, takeptr, count;

  public void put(Object x) 
       throws InterruptedException
  {
    lock.lock();
    try
    {
      while (count == items.length)
       notFull.await();
       
      items[putptr] = x;
      
      if (++putptr == items.length) 
        putptr = 0;
        
      ++count;
      notEmpty.signal();
    }
    finally
    {
      lock.unlock();
    }
  }
  
  public Object take() 
       throws InterruptedException
  {
    lock.lock();
    try
    {
      while (count == 0)
        notEmpty.await();
        
      Object x = items[takeptr];
      
      if (++takeptr == items.length) 
        takeptr = 0;
      --count;
      
      notFull.signal();
      return x;
    }
    finally
    {
      lock.unlock();
    }
  }
}

Depuis bien longtemps, les utilisateurs d'applications écrites en Java demandaient une extension qui leur permet de gérer facilement les événements de la JVM (Java Virtual Machine), et plus particulièrement l'état de la mémoire à bas niveau.

J2SE 1.5 fournit pour cela une extension permettant de supporter ces éléments clés garants de la fiabilité, de la disponibilité et du fonctionnement normal des applications Java.

Elle est composée de deux parties principales :

• l'API JMX (Java Management Extensions) bien connue en tant qu'API externe, qui consiste en un framework d'observation de la JVM. Les caractéristiques internes des données de celle-ci, comme les informations sur les processus et la mémoire sont désormais disponibles pour être publiées via l'interface de MBeans JMX (JSR 003), l'interface distante JMX (JSR 160) ou encore directement via l'espace d'adressage Java. Un ensemble d'outils et de protocoles standard d'accès (JSR163), comme le protocole SNMP (Simple Network Management Protocol), permettent la remontée d'informations vers un moniteur ;
• un outil de « profiling » natif appelé JVMTI, permettant de profiler les applications Java, mais aussi de les superviser, de les déboguer, voire de les manipuler directement au niveau du bytecode, c'est-à-dire à chaud, pendant leur exécution.

Non seulement vous pouvez voir les informations de la JVM, mais le framework fournit les outils permettant d'agir sur celles-ci, d'essayer de nouvelles valeurs, comme changer le niveau de traces fonctionnelles (log) dynamiquement.

JPLIS (Java Programming Language Instrumentation Services) permet d'ajouter des points de contrôle ciblés dans le code, à la manière de la POA (Programmation Orienté Aspect), permettant ainsi une supervision plus fine de la JVM, et ce à chaud, au chargement de l'application, ou encore durant la compilation (opération de tissage).

L'autre fonctionnalité phare de cette API de management est sans nul doute le détecteur de seuil de mémoire. Lorsque le seuil est atteint, une notification peut être envoyée par le bean JMX ou une « trap » SNMP peut être levée. Cela permet par exemple de prévoir une charge importante sur une application et de la gérer avec des machines supplémentaires en répartissant dynamiquement la charge.

La prise en main de cette API est très simple. Par exemple pour définir une supervision de la JVM via le protocole SNMP, on peut très simplement faire :

java -Dcom.sun.management.snmp.acl=false
     -Dcom.sun.management.snmp.port=161
     -Dcom.sun.management.snmp.trap=162
     -jar TestApplication.jar

Les ports utilisés ici sont les ports standard SNMP. De la même manière, il est possible de définir ces options dans un fichier de configuration (management.properties).

Associer un serveur de MBean JMX est tout aussi simple :

java -Dcom.sun.management.jmxremote.authenticate=false
     -Dcom.sun.management.jmxremote.port= 5001
     -Dcom.sun.management.jmxremote.ssl=false
     -jar TestApplication.jar

L'exemple qui suit permet de suivre l'évolution de l'utilisation de la mémoire par la JVM.
Comme nous allons pouvoir le constater, cette fonctionnalité est très simplement prise en charge par l'API de management :

import java.lang.management.*;
import java.util.*;

public class MemTest
{
  public static void main(String args[])
  {
    List<MemoryPoolMXBean> pools = ManagementFactory.getMemoryPoolMXBeans();
    for (MemoryPoolMXBean p: pools)
    {
      System.out.println("Memory type="+p.getType()
      System.out.print("Memory usage="+p.getUsage());
    }
  }
}

Voici le type de sortie que produit le code précédent :

Une autre fonctionnalité très simple à mettre en œuvre est la détection des crashs de la JVM HotSpot suite à une erreur fatale. Il est alors possible de déclencher une commande :

-XX:OnError="command"

Il est aussi possible de brancher un débogueur ou un fichier système lors de cette détection :

-XX:OnError="pmap %p" // %p représente le pid.
-XX:OnError="gdb %p"

Cette API étant très riche et les possibilités qu'elle offre très nombreuses, veuillez vous reporter au site de référence de JMX pour de plus amples informations :

http://java.sun.com/products/JavaManagement/

Tiger améliore grandement le temps de démarrage et la taille mémoire occupée par les applications développées en client lourd.

De plus il introduit un nouveau thème appelé « Ocean », en plus des thèmes « Windows XP » et « GTK » déjà ajoutés dans le J2SE 1.4.2.

Il faut aussi noter que les apparences graphiques sont désormais personnalisables (principe des skins), via des fichiers XML, ou de manière programmatique.

Tiger permet aussi d'utiliser les capacités d'accélération graphique avec OpenGL pour les applications Java développées en utilisant les composants Java2D.

Il suffit pour cela de le spécifier dans la ligne de commande de lancement de l'application :

java -Dsun.java2d.opengl=true -jar Java2DApplication.jar

Pour les utilisateurs du système d'exploitation Linux, il est désormais possible d'utiliser le système graphique X11, via XAWT (sun.awt.X11.XToolkit), une librairie graphique très rapide s'appuyant sur X11, et permettant d'utiliser le protocole XDnD (glisser / déposer) entre les applications Java et des applications comme Mozilla et Star Office.

Comme il est d'usage, cela se fait via la ligne de commande :

java -Dawt.toolkit=sun.awt.motif.MToolkit -jar X11Application.jar

La plupart des programmeurs Java connaissent les tags Javadoc. Nous savons que ces tags qui apparaissent dans les commentaires peuvent être traités par l'utilitaire Javadoc pour générer de la documentation.

Cette notation apporte du sens supplémentaire à un programme, par exemple le tag @deprecated qui indique souvent la méthode suppléante à utiliser.
L'information ajoutée, bien que non déterminante pour le programme, est souvent décisive pour la compréhension de celui-ci.

Pourtant, actuellement, le compilateur et la machine virtuelle ignorent ce type de tags, qui constituent un type d'annotations.

Certains développeurs ont intelligemment détourné leur utilisation pour leur faire exécuter des tâches spécifiques via un interpréteur.
C'est par exemple le cas de l'outil EJBGen qui fournit un ensemble de tags propriétaires qui, une fois reconnus, génèrent un ensemble de classes et fichiers utiles pour construire des EJB, comme les descripteurs de déploiement, les interfaces et le conteneur.
Dans ce type d'approche, nous pouvons aussi citer XDoclet.

Nous le voyons, ce type de métaprogrammation peut apporter beaucoup dans la facilité de développement, la réduction du volume de code, la simplification et la rationalisation des programmes.

Les annotations font partie d'un mécanisme générique qui associe des métadonnées (des informations déclaratives comme des tags) à des éléments d'un programme comme une classe, une méthode, un champ, un paramètre, des variables locales ou un package.

Les annotations s'inscrivent dans l'approche de la programmation déclarative, à opposer à la programmation impérative utilisée dans les programmes Java classiques, avec des instructions à exécuter dans un ordre précis.

La programmation déclarative définit des conditions et laisse le système déterminer comment les satisfaire. Elle décrit donc plus des prédicats que des instructions.

Dans Tiger, le compilateur agit comme un tisseur (weaver). Un tisseur est un compilateur qui compose des programmes à partir d'éléments externes et non connus de l'application tissée.
Le principe du tisseur est notamment très utilisé dans la Programmation Orientée Aspect (POA) utilisant des extensions du langage (par opposition aux frameworks).

Le compilateur de J2SE 1.5 peut stocker des métadonnées dans des classes. La machine virtuelle ou tout autre programme peuvent à tout moment venir lire ces métadonnées pour déterminer la manière d'interagir avec les éléments annotés du programme ou changer leur comportement. En ce sens, le tisseur de Tiger se rapproche d'un tisseur d'aspect.

Une annotation est un modificateur qui peut être utilisé sur n'importe quelle déclaration. Elle contient en général des couples membre/valeur (parfois optionnels, si des valeurs par défaut existent). Il existe trois types d'annotations : normale, repère et membre unique.

Nous allons voir par la suite comment les écrire et les utiliser.

Pour créer une annotation, nous devons tout d'abord définir un type d'annotation.

Un type d'annotation est défini comme une interface avec un symbole « @ » avant celle-ci :

public @interface ExampleAnnotation
{
  String member1;
}

Une fois ce type créé nous pouvons l'utiliser comme ceci :

@ExampleAnnotation (member1=”value1”)
public void doSomething()
{
  ...
}

Une annotation dîtes « normale » est utilisée pour annoter de manière ordinaire un élément du programme :

@NormalAnnotation(name1=”value1”, name2=”value2”)
public void doSomething()
{
  ...
}

Une annotation dîtes « marqueur » ne contient pas de membre.
Une annotation dîtes « membre unique » contient un et un seul membre.

La spécification d'annotation de programme fournit la possibilité d'ajouter des métaannotations, qui sont utilisées pour « annoter » des annotations. La classe java.lang.Annnotation en fournit les moyens.

Voici un exemple plus complet :

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
@Documented
public @interface WithMetaAnnotation
{
  String value;
}

La méta annotation Retention déclare que @WithMetaAnnotation doit être stockée dans une classe et utilisée par la machine virtuelle à l'exécution par réflexion.
La méta annotation Target déclare que @WithMetaAnnotation peut être utilisée pour annoter des méthodes.

Il existe deux types d'annotations standard dans le package java.lang :

L'exemple suivant illustre l'utilisation des annotations standard:

public class Parent
{
  @Deprecated
  public void aMethod(int x)
  {
    System.out.println("Parent.aMethod(int x) called.");
  }
}

Supposons que nous souhaitions définir une classe étendant Parent, qui redéfinit la méthode aMethod():

public class Child extends Parent
{
  @Overrides
  public void aMethod()
  {
    System.out.println("Child.aMethod() called.");
  }
}

Nous avons ici volontairement défini une méthode aMethod() avec une signature différente pour illustrer notre propos. Alors que cette erreur n'aurait auparavant été identifiée qu'à l'exécution et au prix d'une longue recherche, le compilateur du J2SE 1.5 va, à la compilation, lever une erreur :

Si nous corrigeons cette erreur dans la signature, le compilateur va notifier que la méthode est marquée comme dépréciée, puisque dans la super classe aMethod() est annotée avec @deprecated :

Certaines restrictions existent quant à l'utilisation et la déclaration des annotations :

• les annotations sont déclarées comme des interfaces. Cependant il n'est pas possible de faire hériter une annotation d'une autre annotation en utilisant le mot clé extends.
  Il faut pour cela utiliser la métaannotation @Inherited ;
• les méthodes déclarées dans une annotation ne doivent contenir ni paramètre ni paramètre de type formel (voir les generics). Elles doivent en outre ne retourner que des types primitifs, des Strings, des Class, des types énumérés, des types d'annotations ou des tableaux des précédents types ;
• les annotations ne doivent pas contenir de clause throws.

Pour les personnes familières avec les templates en C++, les generics prennent tout leur sens, bien que des différences fondamentales existent.

Par type générique, on entend aussi polymorphisme paramétrique de type.

De manière concise, on peut dire que les types génériques permettent de développer un comportement unique pour des types polymorphes.

En d'autres termes, les generics permettent de s'abstraire du typage des objets lors de la conception et donc de définir des comportements communs, quel que soit le type des objets manipulés.

Le plus simple pour comprendre les generics est d'analyser un exemple type :

List integerList = new ArrayList();
integerList.add(new Integer(1));
Integer i = (Integer)integerList.get(0);

Dans cet exemple, nous remarquons que nous sommes obligés de transtyper explicitement l'objet que l'on récupère de la collection, car la seule chose dont nous sommes sûrs, c'est que l'itérateur retourne un Object.

Ainsi, rien ne nous empêche d'insérer un objet de type String dans la liste :

integerList.add(“exemple”); // (1)

Une telle construction, bien que fausse, ne déclenchera aucune erreur lors de la compilation.
C'est seulement à l'utilisation que le programme lèvera une exception de type java.lang.ClassCastException.

Avec Tiger, il est possible, via une syntaxe particulière, de spécifier explicitement et avant construction, quel sera le type des objets contenus dans la collection :

List integerList<Integer> = new ArrayList<Integer>();
integerList.add(new Integer(1));
Integer i = integerList.get(0);

La syntaxe <Integer> spécifie que le type des objets utilisés avec cette collection est Integer.

Ainsi, l'exemple précédent (1) fera échouer la compilation, car les generics introduisent une vérification de type statique, c'est-à-dire durant la compilation.

En fait, dans Tiger, les collections sont désormais implémentées en utilisant les types génériques.

Quels sont les avantages des generics ? C'est ce que nous allons voir dans le paragraphe suivant.

Le premier avantage des generics réside dans la suppression du contrôle de type à l'exécution.
En effet, étant donné que les éventuelles erreurs de transtypage sont levées à la compilation, il n'est plus nécessaire de contrôler le type à l'exécution.
Ainsi, le code gagne en sécurité et le temps de maintenance éventuel en est très fortement réduit.

D'autre part, nul code supplémentaire à écrire (comme pour les templates C++) pour introduire les generics. La manière de développer ne change donc pas, si ce n'est des différences mineures dans la syntaxe (que nous verrons dans le paragraphe suivant).

Un avantage visible directement est une meilleure lisibilité et une plus grande robustesse du code.

Un autre aspect moins frappant, mais tout aussi important est la possibilité qu'offrent les types génériques de factoriser des comportements.
Les développeurs passent moins de temps à refaire sans cesse la même chose pour des types différents qu'ils doivent manipuler et peuvent ainsi se concentrer sur la logique fonctionnelle de leurs classes.
Le code en est d'autant plus concis et moins éparpillé et gagne ainsi en cohérence, en taille et en qualité.

Nous allons fixer dans ce chapitre un certain nombre d'appellations et de notations.

Comme nous l'avons déjà vu dans le premier exemple, les premiers symboles nouveaux avec les types génériques sont les chevrons < et >.
Ils permettent de définir les paramètres de types formels qui peuvent être utilisés dans toutes les déclarations génériques, et en particulier en lieu et place des types ordinaires (bien qu'il y ait d'importantes restrictions).
À l'invocation de l'objet, toutes les occurrences du paramètre de type formel sont remplacées par le type défini.

Ainsi, l'interface List est définie de la sorte :

public interface List<T>
{
  void add(T t);
  Iterator<T> iterator();
}

T est ici le paramètre de type formel de l'interface List.

J'insiste bien sur le fait que T est un type, et pas une valeur. Nous verrons pourquoi dans le chapitre suivant.

D'autre part, une convention de nommage semble être acceptée par la communauté pour la notation des paramètres de type formel.
Elle recommande l'utilisation d'un caractère unique en majuscule comme E (Element) ou T (Type).

L'autre symbole important pour les generics est le point d'interrogation (?), que l'on appelle aussi wildcard ou inconnue.

Ainsi nous aurions pu écrire :

List unKnownList<?> = new ArrayList<String>();

Il permet de définir la variance d'un type générique.
Il permet de spécifier que n'importe quel type peut convenir comme élément de la liste.

Nous reviendrons plus loin sur les différentes possibilités qu'offre le wildcard.

Nous l'avions déjà évoqué dans l'introduction, les generics ont des différences majeures avec les templates tels que nous les connaissons en C++ par exemple.

Nous avons vu que les occurrences d'un paramètre de type formel étaient remplacées à l'invocation.
À la lecture de ces mots, il est très facile d'extrapoler le code précédent d'une List qui aurait pour type String par exemple :

public interface StringList
{
  void add(String t);
  Iterator<String> iterator();
}

Ce mécanisme ne doit pas aller sans rappeler aux développeurs C++ les templates.

Et bien cette extrapolation est fausse, et c'est en cela que les templates et les generics sont différents. En effet, il n'y a pas de multiples copies du code, en fonction du type, ni en mémoire, ni dans les sources, ni dans le bytecode généré.

Un generics est compilé une fois pour toutes en une unique classe comme une classe ou une interface classique et l'instance de cette classe est partagée entre toutes les invocations :

List<String> l1 = new ArrayList<String>();
List<Integer> l2 = new ArrayList<Integer>();
boolean jvmIdentity = (l1.getClass() == l2.getClass());

Ainsi, la valeur booléenne jvmIdentity vaut true.

Les paramètres de type formel sont tout simplement remplacés à l'invocation comme les valeurs formelles le sont dans des classes ordinaires, avec la valeur courante du type donnée dans la construction du code (resp. la valeur donnée).

L'héritage avec les generics est une des choses les plus ardues à comprendre, car elle va à contresens des réflexions a priori.

En effet, si une classe C' hérite d'une classe C, et G est un generics de paramètre T, alors il est faux de dire que G<C'> hérite de G<C>. Pourtant cela semblerait être logique.

Voyons cela avec un exemple.

Supposons que nous disposions de la liste des habitants d'une ville et de la liste des clients d'un magasin de cette ville. Nous supposons aussi que la classe Customer hérite de la classe Resident.

List<Customer> customers = new ArrayList<Customer>;

Si nous supposons que tous les clients habitent la ville, on peut penser initialiser la liste des habitants comme ceci :

List<Resident> residents = customers;

Or cette initialisation est fausse; une liste de Resident n'est pas une liste de Customer. Nous allons voir pourquoi cette initialisation pose problème.

Supposons que l'initialisation de la liste des habitants se soit poursuivie comme ceci, sans l'erreur précédente :

residents.add(new Resident(…));

Si par la suite nous tentons de récupérer le premier client de la liste des clients, nous faisons naturellement :

Customer c = customers.get(0);

Or dans cette instruction nous tentons d'assigner à une instance de Customer une instance de Resident, puisque nous avons ajouté un habitant à la liste des habitants et que nous avons créé un alias entre les deux listes.

Cela ne poserait pas de problème si la liste des habitants était immuable. Or ce n'est pas le cas. En réalité, ce qui est passé à la liste des habitants est une copie de la liste des résidents. Sinon, le service commercial du magasin pourrait ajouter à sa liste de clients des personnes qui ne sont pas clientes.

C'est pour cela que le compilateur de J2SE 1.5 lève une erreur de compilation pour la seconde instruction.
Ceci est pour le moins restrictif, et pour pallier cela, Tiger comporte un mécanisme permettant de passer outre : il s'agit de l'utilisation du wildcard.

La variance désigne les limites de portée d'un type générique.

Elle peut se définir comme les limites de la portée d'un type classique par les mots clés extends, super et implements et s'utilise de la même manière.
Pour combiner deux limites sur un même type, il faut utiliser le caractère &.

La construction respecte la règle suivante :

TypeVariable keyword Bound1 & Bound2 & ... & Boundn

Voici un exemple de limite complexe :

final class Foo<A extends Comparable<A> & Cloneable<A>, 
                   B extends Comparable<B> & Cloneable<B>>
  implements Comparable<Foo<A,B>>, 
             Cloneable<Foo<A,B>>
{
  ...
}

Supposons que la mairie de la ville souhaite envoyer un courrier à tous ses habitants qui sont clients du magasin. Le service informatique de la mairie a une méthode permettant d'envoyer un courrier aux habitants de la ville.

Nous aurions une méthode qui ressemble à celle-ci :

void mailResidents(List<Resident> residents)
{
  for(Resident r : residents)
  {
    sendMail(r);
  }
}

Nous tenterions de l'utiliser comme ceci:

List<Customer> customers = ...
...
mailResidents(customers);

Or nous avons vu dans le chapitre précédent qu'il est impossible d'assigner à une liste d'habitants une liste de clients.

Quelle est alors l'alternative ? Il est tout à fait normal de vouloir (et pouvoir …) faire ce type d'opération. Pour cela nous avons le wildcard (?).

Nous pouvons en effet modifier la méthode mailResidents() afin qu'elle accepte n'importe quel type d'individu :

void mailResidents(List<?> persons)
{
  for(Person p : persons)
  {
    sendMail(p);
  }
}

Si nous souhaitons que le système se limite à tout type d'individu, pour peu que ceux-ci soient des habitants de la ville, nous pouvons écrire :

void mailResidents(List<? extends Resident> residents)
{
  for(Resident r : residents)
  {
    sendMail(r);
  }
}

Ainsi, comme Customer hérite de Resident, l'utilisation de la méthode devient valide dans notre exemple précédent. Dans ce cas, la classe Resident est dite la classe « upper bound » de la classe Customer.

Cette construction a pourtant une limitation. Il est en effet impossible de modifier la liste dans le corps de la méthode, car comme nous ne connaissons pas le type effectif (si ce n'est que c'est un type inconnu dont le supertype est Resident). Toute tentative d'ajout d'élément nous confronterait à un problème de compatibilité de type entre le type effectif et le type de l'objet à ajouter.

Tiger encore une fois propose une possibilité pour outrepasser ceci. Il s'agit des méthodes génériques.

Les méthodes génériques sont des méthodes qui sont paramétrées par des types génériques. Nous allons voir comment celles-ci se mettent en œuvre.

Supposons que le service du recensement fournisse à la mairie une liste de personnes nouvellement installées dans la commune. La mairie souhaite alors mettre à jour sa liste d'habitants. La classe NewComer hérite de la classe Resident.

La mairie dispose pour cela de la méthode suivante :

static void addResidents(List<? extends Resident> newComers,
                         List<Resident> residents)
{
  for(Resident n: newComers)
  {
    residents.add(n); // erreur de compilation
  }
}

Nous avons bien pris soin de spécifier que les éléments de la liste des résidents sont de tous types héritant de Resident. Cependant comme nous venons de le dire, il est impossible de modifier la liste passée en paramètre. La ligne 6 provoque donc une erreur de compilation.

Les méthodes génériques arrivent ici à point nommé en déduisant le type à assigner :

static <T extends Resident> void addResidents(List<T> newComers,
                         List<Resident> residents)
{
  for(T n: newComers)
  {
    residents.add(n); // pas d'erreur ici.
  }
}

Jusqu'ici nous avons toujours remplacé du code classique par du code générique. Or, dans une application existante, il ne sera sans doute pas possible de tout refaire en utilisant les generics.

On peut isoler deux cas principaux :

• nous utilisons du code générique au sein d'un code ordinaire ;
• nous ajoutons du code existant ordinaire dans du code générique.

Dans le premier cas, le compilateur va lever des avertissements sur les blocs de code qui pourraient poser problème, par exemple des collections classiques qui utilisent des collections génériques.

Dans le second cas, le compilateur va convertir le code générique en code ordinaire. Ce processus est appelé « erasure and translation ». Il supprime toutes les informations génériques et transtype les objets dans un type compatible (voire Object si aucun type n'est compatible).