Packages

images/whitebelt.png

Dans la mesure où elle est basée sur l’utilisation de "composants" l’exécution de code Java implique la collaboration (éventuellement dynamique) de codes venant de fournisseurs différents.

Il ne doit pas y avoir de conflit entre les noms de types : Il y a en fait deux types nommés List dans les librairies standard java …. mais ce n’est pas leur nom complet! Les types définis par les programmeurs ont un nom canonique qui comprend le nom d’un package.

Il est illégal de créer un type qui ne soit pas hébergé dans un package ( à moins que ce soit un test local ou une petite démonstration). De plus on ne livre jamais un code isolé (même au niveau d’un changement de version de ce seul code): on déploie toujours un package complet.

Les types définis par l’utilisateur doivent avoir un nom canonique qui est garanti unique. Donc un nom de package est composé :

Tous ces noms sont en minuscules (et ne peuvent pas contenir des caractères réservés de Java, ni de nombres - ni de caractères accentués-). Quelques exemples:

   com.acme.produits.trucs.CycloRameur
   fr.grosse_boite.division_financiere.calculs.swaps.Swap
   org.oecd.admin.Swap
   java.awt.Button
   javax.swing.table.TableColumn
[Avertissement]Attention

Pour le lancement d’une application java il faut fournir le nom canonique de la classe qui fournit le point d’entrée:

java com.acme.produits.trucs.TestMain

Pour qu’une classe fasse partie d’un package la première ligne significative de son code source doit contenir une directive package.

Une classe dans un package. 

package com.acme.produits.trucs ; // directive de compilation

public class CycloRameur {
   //code
   public CycloRameur(java.awt.Color color) {
      //code
   }
}

[Avertissement]Attention

Un code situé dans un package ne peut pas faire appel à un code qui ne fait pas lui même partie d’un package (par ex. les codes des classes que nous avions écrites sans la directive package)!

directives import

images/whitebelt.png

Les noms canoniques de types sont ceux qui sont utilisés par le pseudo-code du binaire. On pourrait les utiliser dans le code source en écrivant:

   new com.acme.produits.trucs.CycloRameur(java.awt.Color.Blue) ;

Bien sûr nous préfererions écrire :

   new CycloRameur(Color.Blue) ;

et laisser le compilateur résoudre le "vrai" nom de la classe pour nous!

Pour permettre cela il faut utiliser des directives de compilation: celles-ci se trouvent après la directive package et avant toute déclaration de type:

directives import. 

package com.acme.ventes ;

import com.acme.produits.trucs.CycloRameur ;
import java.awt.Color ; // preferer les import explicites
import java.util.* ; // import implicite

public class ShowBiz {
   // quelque part dans le code
      new CycloRameur(Color.BLUE) ;
}

  • On n’a pas besoin d’utiliser import pour des types appartenant au package courant (le package de la classe courante).
  • Il vaut mieux toujours préférer des imports explicites: la notation "étoilée peut conduire à des conflits (Il y a deux types nommés List et si on utilise import java.util.* ; et import java.awt.* ; il y a conflit de nommage). De plus on peut se tromper au niveau de l’expansion de la notation "*" : la directive import java.util.* ; ne permet pas de résoudre le nom de java.util.logging.Logger (l’expansion ne concerne pas les sous-packages).
  • import est une directive de compilation: il n’y a aucun effet au runtime. Quand il a besoin de faire un contrôle sémantique le compilateur cherche à charger le pseudo-code de la classe correspondante et vérifie s’il est utilisé correctement.

import static

images/whitebelt.png

Le compilateur peut aussi compléter automatiquement les noms des membres statiques:

import static. 

package com.acme.ventes ;

import com.acme.produits.trucs.CycloRameur
import java.awt.Color ; // preferer import explicite
import static java.awt.Color.* ; // nom canonique du type est nécessaire
import java.util.* ;

public class ShowBiz {
   // quelque part dans le code
      new CycloRameur(BLUE) ; // argument traduit en java.awt.Color.BLUE
}

[Attention]Attention

Ne pas abuser de cette facilité! Il serait peu opportun de donner aux méthodes statiques un aspect de fonction (qui n’existent pas en Java). -Malheureusement quelques frameworks ont pris cette mauvaise habitude-