Thinking in Java, 3rd ed. Revision 4.0

Un package est ce qui devient disponible lorsqu'on utilise le mot-clé import pour importer une bibliothèque complète, par exemple:

import java.util.*;

Cette instruction importe la bibliothèque complète d'utilitaires qui font partie de la distribution Java standard. Il existe par exemple une classe nommée ArrayList dans java.util, on peut maintenant soit spécifier le nom complet java.util.ArrayList (ce que l'on peut faire sans l'instruction import), ou alors simplement dire ArrayList (grâce à l'instruction import).

Si on veut importer une seule classe, on peut la nommer dans l'instruction import :

import java.util.ArrayList;

Maintenant on peut utiliser ArrayList sans préciser son chemin. Cependant, aucune des autres classes de java.util ne sera disponible.

La raison d'être de tout ce mécanisme d'imports est de fournir un mécanisme pour gérer les « espaces de nommage » [name spaces]. Les noms de tous les membres de classe sont isolés les uns des autres. Une méthode f( ) dans une classe A ne sera pas en conflit avec une f( ) qui a la même signature (liste d'arguments) dans une classe B. Mais qu'en est-il des noms des classes ? Que se passerait-il si on créait une classe Stack sur une machine qui a déjà une classe Stack écrite par quelqu'un d'autre ? La probabilité de collision des noms explique l'importance d'avoir un contrôle total sur les noms d'espace en Java, et d'être à même de créer un nom unique sans avoir à se soucier des contraintes d'Internet.

Pour l'instant, la plupart des exemples de ce livre étaient constitués dans un seul fichier, ont été conçus pour un usage en local, et ne se sont pas préoccupés de noms de packages (dans ce cas le nom de la classe est placé dans le « package par défaut » ). C'est une possibilité, et dans un but de simplicité cette approche sera utilisée autant que possible dans le reste de ce livre. Cependant, si on envisage de créer des bibliothèques ou des programmes pouvant coexister avec d'autres programmes sur la même machine, il faut penser à se prémunir des conflits de noms de classes.

Quand on crée un fichier source pour Java, on l'appelle couramment unité de compilation [compilation unit] (parfois une unité de traduction [translation unit]). Chaque unité de compilation doit avoir un nom se terminant par .java, et dans l'unité de compilation il peut y avoir une classe public qui doit avoir le même nom que le fichier (y compris les majuscules et minuscules, mais sans l'extension .java). Il ne peut y avoir qu'une seule classe public dans chaque unité de compilation, sinon le compilateur sortira une erreur. Le reste des classes de cette unité de compilation, s'il y en a, sont cachées du monde extérieur parce qu'elles ne sont pas public, ce sont des classes « support » pour la classe public principale.

Quand on compile un fichier .java, on obtient un fichier de sortie pour chaque classe de ce fichier. Chaque fichier de sortie a le nom d'une classe se trouvant dans le fichier .java, mais avec une extension .class. De ce fait on peut obtenir un nombre important de fichiers .class à partir d'un petit nombre de fichiers .java. Si vous avez programmé avec un langage compilé, vous êtes peut être familier avec le fait que le compilateur génère un fichier dans un format intermédiaire (généralement un fichier « obj » ) qui est ensuite assemblé avec d'autres fichiers de ce type à l'aide d'un éditeur de liens [linker] (pour créer un fichier exécutable) ou un « gestionnaire de bibliothèque » [librarian] (pour créer une bibliothèque). Java ne se comporte pas ainsi. Un programme exécutable est un ensemble de fichiers .class, qui peuvent être empaquetés [packaged] et compressés dans un fichier JAR (en utilisant l'utilitaire de compression Java jar). L'interpréteur Java se charge de la recherche, du chargement et de l'interprétation de ces fichiers. (26)

Une bibliothèque est un ensemble de ces fichiers classes. Chaque fichier possède une classe qui est public (on n'est pas obligé d'avoir une classe public, mais c'est ce qu'on fait généralement), de sorte qu'il y a un composant pour chaque fichier. Si on veut spécifier que tous ces composants (qui sont dans leurs propres fichiers .java et .class séparés) soient reliés entre eux, c'est là qu'intervient le mot-clé package.

Quand on spécifie:

package mypackage;

au début d'un fichier (si on utilise l'instruction package, elle doit apparaître à la première ligne du fichier, commentaires mis à part), on déclare que cette unité de compilation fait partie d'une bibliothèque appelée mypackage. Ou, dit autrement, cela signifie que le nom de la classe public dans cette unité de compilation est sous la couverture du nom mypackage, et si quelqu'un veut utiliser ce nom, il doit soit spécifier le nom complet, soit utiliser le mot-clé import en combinaison avec mypackage (utilisation des choix donnés précédemment). Remarquez que la convention pour les noms de packages Java est de n'utiliser que des lettres minuscules, même pour les mots intermédiaires.

Par exemple, supposons que le nom du fichier est MyClass.java. Ceci signifie qu'il peut y avoir une et une seule classe public dans ce fichier, et que le nom de cette classe doit être MyClass (sensible à la casse)

package mypackage;
public class MyClass {
    // . . .

Maintenant, si quelqu'un désire faire appel à MyClass, ou aussi bien, une des autres classes public de mypackage, il doit utiliser le mot-clé import pour avoir à sa disposition le ou les noms définis dans mypackage. L'autre solution est de donner le nom complet :

mypackage.MyClass m = new mypackage.MyClass();

Le mot clef import peut rendre cela bien plus clair :

import mypackage.*;
// . . . 
MyClass m = new MyClass();

Il est important de garder à l'esprit que ce que permettent les mots-clés package et import, en tant que concepteur de bibliothèque, c'est de diviser l'espace de nommage global afin d'éviter le conflit de nommages, indépendamment de combien il y a de personnes qui vont sur Internet écrire des classes en Java.

V-A-1. Créer des noms de packages uniques▲

package com.bruceeckel.simple;

//: com:bruceeckel:simple:Vector.java
// Création d'un package.
package com.bruceeckel.simple;

public class Vector {
    public Vector() {
        System.out.println("com.bruceeckel.simple.Vector");
    }
} ///:~

//: com:bruceeckel:simple:List.java
// Création d'un package.
package com.bruceeckel.simple;

public class List {
    public List() {
        System.out.println("com.bruceeckel.simple.List");
    }
} ///:~

C:\DOC\JavaT\com\bruceeckel\simple

CLASSPATH=.;D:\JAVA\LIB;C:\DOC\JavaT

CLASSPATH=.;D:\JAVA\LIB;C:\flavors\grape.jar

//: c05:LibTest.java
// Utilise la bibliothèque.
import com.bruceeckel.simpletest.*;
import com.bruceeckel.simple.*;

public class LibTest {
    static Test monitor = new Test();
    public static void main(String[] args) {
        Vector v = new Vector();
        List l = new List();
        monitor.expect(new String[] {
            "com.bruceeckel.simple.Vector",
            "com.bruceeckel.simple.List"
        });
    }
} ///:~

import com.bruceeckel.simple.*;
import java.util.*;

Vector v = new Vector();

java.util.Vector v = new java.util.Vector();

V-A-2. Une bibliothèque d'outils personnalisée▲

//: com:bruceeckel:tools:P.java
// Les raccourcis P.rint & P.rintln.
package com.bruceeckel.tools;

public class P {
    public static void rint(String s) {
        System.out.print(s);
    }
    public static void rintln(String s) {
        System.out.println(s);
    }
} ///:~

//: c05:ToolTest.java
// Utilise la bibliothèque tools
import com.bruceeckel.tools.*;
import com.bruceeckel.simpletest.*;

public class ToolTest {
    static Test monitor = new Test();
    public static void main(String[] args) {
        P.rintln("Available from now on!");
        P.rintln("" + 100); // Le force à être une String
        P.rintln("" + 100L);
        P.rintln("" + 3.14159);
        monitor.expect(new String[] {
            "Available from now on!",
            "100",
            "100",
            "3.14159"
        });
    }
} ///:~

V-A-3. Utilisation des imports pour modifier le comportement▲

V-A-4. Mise en garde sur les packages▲

Quand on les utilise, les spécificateurs d'accès Java public, protected, et private sont placés devant la définition de chaque membre de votre classe, qu'il s'agisse d'un champ ou d'une méthode. Chaque spécificateur d'accès contrôle l'accès pour uniquement cette définition particulière. Ceci est différent du C++, où un spécificateur d'accès contrôle toutes les définitions le suivant jusqu'à ce qu'un autre spécificateur d'accès soit rencontré.

D'une façon ou d'une autre, toute chose a un type d'accès spécifié. Dans les sections suivantes, vous apprendrez à utiliser les différents types d'accès, à commencer par l'accès par défaut.

V-B-1. Accès package▲

V-B-2. public : accès d'interface▲

//: c05:dessert:Cookie.java
// Création d'une bibliothèque.
package c05.dessert;

public class Cookie {
    public Cookie() {
        System.out.println("Cookie constructor");
    }
    void bite() { System.out.println("bite"); }
} ///:~

//: c05:Dinner.java
// Utilise la bibliothèque.
import com.bruceeckel.simpletest.*;
import c05.dessert.*;

public class Dinner {
    static Test monitor = new Test();
    public Dinner() {
        System.out.println("Dinner constructor");
    }
    public static void main(String[] args) {
        Cookie x = new Cookie();
        //! x.bite(); // Ne peut y accéder
        monitor.expect(new String[] {
            "Cookie constructor"
        });
    }
} ///:~

//: c05:Cake.java
// Accède à une classe dans une unité de compilation séparée.
import com.bruceeckel.simpletest.*;

class Cake {
    static Test monitor = new Test();
    public static void main(String[] args) {
        Pie x = new Pie();
        x.f();
        monitor.expect(new String[] {
            "Pie.f()"
        });
    }
} ///:~

//: c05:Pie.java
// L'autre classe.

class Pie {
    void f() { System.out.println("Pie.f()"); }
} ///:~

V-B-3. private : ne pas toucher !▲

//: c05:IceCream.java
// Démontre le mot-clé « private »

class Sundae {
    private Sundae() {}
    static Sundae makeASundae() {
        return new Sundae();
    }
}

public class IceCream {
    public static void main(String[] args) {
        //! Sundae x = new Sundae();
        Sundae x = Sundae.makeASundae();
    }
} ///:~

V-B-4. protected : accès pour l'héritage▲

class Foo extends Bar {

//: c05:ChocolateChip.java
// Ne peut pas accéder à un membre accès package d'un autre package.
import com.bruceeckel.simpletest.*;
import c05.dessert.*;

public class ChocolateChip extends Cookie {
    private static Test monitor = new Test();
    public ChocolateChip() {
        System.out.println("ChocolateChip constructor");
    }
    public static void main(String[] args) {
        ChocolateChip x = new ChocolateChip();
        //! x.bite(); // Ne peut pas accéder à bite
        monitor.expect(new String[] {
            "Cookie constructor",
            "ChocolateChip constructor"
        });
    }
} ///:~

public class Cookie {
    public Cookie() { 
        System.out.println("Cookie constructor");
    }
    protected void bite() {
    System.out.println("bite"); 
    }
}

Le contrôle d'accès est souvent appelé cacher l'implémentation. L'enveloppement des données et méthodes à l'intérieur des classes combiné au masquage de l'implémentation est souvent appelé encapsulation. (29) Le résultat est un type de données avec des caractéristiques et des comportements.

Le contrôle d'accès pose des limites sur un type de données pour deux raisons importantes. La première est de déterminer ce que les programmeurs clients peuvent et ne peuvent pas utiliser. On peut construire les mécanismes internes dans la structure sans se préoccuper du risque que les programmeurs clients prennent ces mécanismes internes comme faisant partie de l'interface qu'ils doivent utiliser.

Ceci amène directement à la deuxième raison, qui est de séparer l'interface de son implémentation. Si la structure est utilisée dans un ensemble de programmes, mais que les programmeurs clients ne peuvent qu'envoyer des messages à l'interface public, alors vous êtes libre de changer tout ce qui n'est pas public (e.g. accès package, protected, ou private) sans casser le code client.

Nous sommes maintenant dans le monde de la programmation orientée objet (POO), dans lequel une class décrit en fait « une classe d'objets », comme on décrirait une classe des poissons ou une classe des oiseaux. Tout objet appartenant à cette classe partage ces caractéristiques et comportements. La classe est une description de la façon dont les objets de ce type vont nous apparaître et se comporter.

Dans le langage de POO d'origine, Simula-67, le mot-clé class était utilisé pour décrire un nouveau type de données. Le même mot-clé a été repris dans la plupart des langages orientés objet. Ceci est le point central de tout le langage : la création de nouveaux types de données qui sont plus que simplement des boîtes contenant des données et des méthodes.

La classe est le concept de POO fondamental en Java. C'est l'un des mots-clés qui ne sera pas mis en gras dans ce livre, ça devient pénible pour un mot aussi souvent répété que « class »

Pour plus de clarté, il est préférable d'utiliser un style de création des classes qui place les membres public au début, suivi par les membres protected, accès package, et private. L'avantage de ceci est que l'utilisateur de la classe peut lire de bas en haut et voir en premier ce qui est important pour lui (les membres public, parce qu'ils sont accessibles de l'extérieur du fichier), et en s'arrêtant lorsqu'il rencontre les membres non public, qui font partie de l'implémentation interne :

public class X {
    public void pub1() { /* . . . */ }
    public void pub2() { /* . . . */ }
    public void pub3() { /* . . . */ }
    private void priv1() { /* . . . */ }
    private void priv2() { /* . . . */ }
    private void priv3() { /* . . . */ }
    private int i;
    // . . .
}

Ceci ne la rendra que partiellement plus lisible parce que l'interface et l'implémentation sont encore mélangées. C'est-à-dire qu'on voit toujours le code source - l'implémentation - parce qu'il est là dans la classe. De plus, la documentation sous forme de commentaires supportée par la Javadoc (décrite au chapitre 2) diminue l'importance de la lisibilité du code par le programmeur client. Afficher l'interface au consommateur d'une classe est normalement le travail du navigateur de classes, un outil dont le travail consiste à inspecter toutes les classes disponibles et de montrer ce qu'on peut en faire (i.e. quels membres sont disponibles) de façon pratique. Les navigateurs de classe sont devenus une partie attendue de tout bon outil de développement Java.

En Java, les spécificateurs d'accès peuvent aussi être utilisés pour déterminer quelles classes d'une bibliothèque seront accessibles aux utilisateurs de cette bibliothèque. Si on désire qu'une classe soit disponible pour un programmeur client, on place le mot-clé dans la définition de la classe. Ceci contrôle si le programmeur client peut même créer un objet de la classe.

Pour contrôler l'accès à la classe, le spécificateur doit apparaître avant le mot-clé class. On peut donc dire :

public class Widget {

Maintenant, si le nom de la bibliothèque est mylib, tout programmeur client peut accéder à Widget en disant

import mylib.Widget;

ou

import mylib.*;

Il y a cependant un ensemble de contraintes supplémentaires :

• Il ne peut y avoir qu'une seule classe public par unité de compilation (fichier). L'idée est que chaque unité de compilation a une seule interface publique représentée par cette classe public. Elle peut avoir autant de classes en accès-package que l'on veut. Si on a plus d'une classe public dans une unité de compilation, le compilateur générera un message d'erreur.
• Le nom de la classe public doit correspondre exactement au nom du fichier contenant l'unité de compilation, casse comprise. Par exemple pour Widget, le nom du fichier doit être Widget.java, et pas widget.java ou WIDGET.java. Là aussi on obtient des erreurs de compilation s'ils ne correspondent pas.
• Il est possible, bien que non habituel, d'avoir une unité de compilation sans aucune classe public. Dans ce cas, on peut appeler le fichier comme on veut.

Que se passe-t-il si on a une classe dans mylib qu'on utilise uniquement pour accomplir les tâches effectuées par Widget ou une autre classe public de mylib ? On ne veut pas créer de documentation pour un programmeur client, et on pense que peut-être plus tard on modifiera tout et qu'on refera toute la classe en lui en substituant une nouvelle. Pour garder cette possibilité, il faut s'assurer qu'aucun programmeur client ne devienne dépendant des détails d'implémentation cachés dans mylib. Pour réaliser ceci, il suffit d'enlever le mot-clé public de la classe, qui devient dans ce cas en accès package. (Cette classe ne peut être utilisée que dans ce package.)

Quand on créé une classe en accès package, cela a encore un sens de rendre des champs de cette classe private- Il faudrait toujours mettre les champs privés autant que possible-, mais il est généralement raisonnable de donner aux méthodes le même accès qu'à la classe (accès package). Puisqu'une classe en accès package est habituellement utilisée dans un package, vous avez seulement besoin de mettre les méthodes d'une telle classe public si vous êtes obligé, et dans ces cas, le compilateur vous avertira.

Remarquer qu'une classe ne peut pas être private (cela la rendrait inaccessible à personne, mais seulement à la classe) ou protected. (30) Il n'y a donc que deux choix pour l'accès aux classes : accès package ou public. ce qui empêche tout le monde de créer un objet de cette classe, à part soi-même, dans un membre static de la classe, en créant un objet de cette classe. Voici un exemple :

//: c05:Lunch.java
// Démontre les spécificateurs d'accès de classes.
// Faire une classe effectivement private
// avec des constructeurs private :

class Soup {
    private Soup() {}
    // (1) Permettre la création à l'aide d'une méthode static :
    public static Soup makeSoup() {
        return new Soup();
    }
    // (2) Créer un objet static et retourner une référence à la demande.
    // (le patron "Singleton"):
    private static Soup ps1 = new Soup();
    public static Soup access() {
        return ps1;
    }
    public void f() {}
}

class Sandwich { // Utilise Lunch
    void f() { new Lunch(); }
}

// // Une seule classe public autorisée par fichier :
public class Lunch {
    void test() {
         // Ne peut pas faire ceci ! Constructeur privé :
        //! Soup priv1 = new Soup();
        Soup priv2 = Soup.makeSoup();
        Sandwich f1 = new Sandwich();
        Soup.access().f();
    }
} ///:~

Jusqu'ici, la plupart des méthodes retournaient soit void soit un type primitif, ce qui fait que la définition :

public static Soup access() {
    return ps1;
}

pourrait paraître un peu confuse. Le mot devant le nom de la méthode (access) dit ce que retourne la méthode. Jusqu'ici cela a été le plus souvent void, ce qui signifie qu'elle ne retourne rien. Mais on peut aussi retourner la référence à un objet, comme c'est le cas ici. Cette méthode retourne une référence à un objet de la classe Soup.

La classe Soup montre comment empêcher la création directe d'une classe en rendant tous les constructeurs private. Souvenez-vous que si vous ne créez pas explicitement au moins un constructeur, le constructeur par défaut (un constructeur sans arguments) sera créé pour vous. En écrivant ce constructeur par défaut, il ne sera pas créé automatiquement. En le rendant private, personne ne pourra créer un objet de cette classe. Mais alors comment utilise-t-on cette classe ? L'exemple ci-dessus montre deux possibilités. Premièrement, une méthode static est créée, elle crée un nouveau Soup et en retourne la référence. Ceci peut être utile si on veut faire des opérations supplémentaires sur Soup avant de le retourner, ou si on veut garder un compteur du nombre d'objets Soup créés (peut-être pour restreindre leur population).

La seconde possibilité utilise ce qu'on appelle un patron de conception [design pattern], qui est expliqué dans Thinking in Patterns (with Java) sur www.BruceEckel.com.Ce patron particulier est appelé un « singleton » parce qu'il n'autorise la création que d'un seul objet. L'objet de classe Soup est créé comme un membre static private de Soup, ce qui fait qu'il n'y en a qu'un seul, et on ne peut y accéder qu'à travers la méthode public access( ).

Comme mentionné précédemment, si on ne met pas de spécificateur d'accès il est en accès package par défaut. Ceci signifie qu'un objet de cette classe peut être créé par toute autre classe du package, mais pas en dehors du package souvenez-vous que tous les fichiers dans le même répertoire qui n'ont pas de déclaration package explicite font implicitement partie du package par défaut pour ce répertoire). Cependant, si un membre static de cette classe est public, le programmeur client peut encore accéder à ce membre static même s'il ne peut pas créer un objet de cette classe.

Dans toute relation il est important d'avoir des limites respectées par toutes les parties concernées. Lorsque l'on crée une bibliothèque, on établit une relation avec l'utilisateur de cette bibliothèque - le programmeur client - qui est un autre programmeur, mais qui construit une application ou qui utilise la bibliothèque pour créer une bibliothèque plus grande.

Sans règles, les programmeurs clients peuvent faire tout ce qu'ils veulent des membres de la classe, même si vous préféreriez qu'ils ne manipulent pas directement certains des membres. Tout est à découvert dans le monde entier.

Ce chapitre a décrit comment les classes sont construites pour former des bibliothèques : premièrement, comment un groupe de classes est empaqueté dans une bibliothèque, et deuxièmement, comment la classe contrôle l'accès à ses membres.

On estime qu'un projet programmé en C commence à s'écrouler lorsqu'il atteint 50K ou 100K lignes de code parce que le C a un seul « espace de nommage » : et donc les noms commencent à entrer en conflit, provoquant un surcroît de gestion. En Java, le mot-clé package, le principe de nommage des packages, et le mot-clé import donnent un contrôle complet sur les noms, et le problème de conflit de nommage est facilement évité.

Il y a deux raisons pour contrôler l'accès aux membres. La première est d'écarter les utilisateurs des outils qu'ils ne devraient pas utiliser : outils qui sont nécessaires pour les traitements internes des types de données, mais qui ne font pas partie de l'interface dont les utilisateurs ont besoin pour résoudre leurs problèmes particuliers. Ainsi créer des méthodes et des champs private est un service pour les utilisateurs, parce qu'ils peuvent facilement voir ce qui est important pour eux et ce qu'ils peuvent ignorer. Cela simplifie leur compréhension de la classe.

La deuxième raison, et la plus importante, pour le contrôle d'accès, est de permettre au concepteur de bibliothèque de modifier les fonctionnements internes de la classe sans se soucier de la façon dont cela peut affecter le programmeur client. On peut construire une classe d'une façon, et ensuite découvrir qu'une restructuration du code améliorera grandement sa vitesse. Si l'interface et l'implémentation sont clairement séparées et protégées, on peut y arriver sans forcer l'utilisateur à réécrire son code.

Les spécificateurs d'accès en Java donnent un contrôle précieux au créateur d'une classe. Les utilisateurs de la classe peuvent voir clairement et exactement ce qu'ils peuvent utiliser et ce qu'ils peuvent ignorer. Encore plus important, on a la possibilité de garantir qu'aucun utilisateur ne deviendra dépendant d'une quelconque partie de l'implémentation sous-jacente d'une classe. Sachant cela en tant que créateur d'une classe, vous pouvez modifier l'implémentation comme vous le voulez, parce que vous savez qu'aucun programmeur client ne sera affecté par les modifications ; n'ayant pas accès à cette partie de la classe.

Lorsqu'on a la possibilité de modifier l'implémentation, on peut améliorer librement la conception. On a aussi la liberté de faire des erreurs. Quel que soit le soin que vous apportez à votre plan et à votre conception, vous ferez des erreurs. Savoir qu'il est relativement peu dangereux de faire ces erreurs veut dire que vous ferez plus d'expériences, vous apprendrez plus vite, et vous finirez plus vite votre projet.

L'interface publique d'une classe est ce que l'utilisateur voit, donc c'est la partie qui doit être « correcte » lors de l'analyse et la conception. Même ici vous avez encore quelques possibilités de modifications. Si vous n'avez pas la bonne interface la première fois, vous pouvez ajouter des méthodes, tant que vous ne supprimez pas celles que les programmeurs clients ont déjà utilisées dans leur code.

Les solutions des exercices sélectionnés sont disponibles dans le document électronique The Thinking in Java Annotated Solution Guide, disponible à un prix raisonnable sur www.BruceEckel.com.

1. Écrivez un programme qui crée un objet ArrayList sans importer explicitement java.util.*.
2. Dans la section nommée « package : l'unité de bibliothèque », transformez les fragments de code concernant mypackage en un ensemble de fichiers Java qui peuvent être compilés et qui tournent.
3. Dans la section appelée « Collisions », prenez les fragments de code et transformez-les en programme, et vérifiez qu'en fait les collisions arrivent.
4. Généralisez la classe P définie dans ce chapitre en ajoutant toutes les versions surchargées de rint( ) et rintln( ) nécessaires pour gérer tous les types Java de base.
5. Créez une classe avec des champs et méthodes membres public, private, protected, et en accès package. Créez un objet de cette classe et voyez quel type de messages du compilateur vous obtenez quand vous essayez d'accéder à tous les membres. Faites attention au fait que des classes dans un même répertoire font partie d'un package « par défaut ».
6. Créez une classe avec des données protected. Créez une deuxième classe dans le même fichier avec une méthode qui manipule la donnée protected de la première classe.
7. Modifiez la classe Cookie comme spécifié dans la section « protected : accès pour l'héritage ». Vérifiez que bite( ) n'est pas public.
8. Dans la section nommée « Accès aux classes » vous trouverez des fragments de code décrivant mylib et Widget. Créez cette bibliothèque, et ensuite créez un Widget dans une classe qui ne fait pas partie du package mylib.
9. Créez un nouveau répertoire et modifiez votre CLASSPATH pour inclure ce nouveau répertoire. Copiez le fichier P.class file (produit par la compilation de com.bruceeckel.tools.P.java) dans votre nouveau répertoire et changez ensuite le nom du fichier, la classe P à l'intérieur, et les noms de méthodes (vous pouvez aussi ajouter des sorties supplémentaires pour observer comment cela fonctionne). Créez un autre programme dans un autre répertoire, qui utilise votre nouvelle classe.
10. En suivant la forme de l'exemple Lunch.java, créez une classe appelée ConnectionManager qui gère un tableau fixe d'objets Connection. Le programmeur client ne doit pas pouvoir créer explicitement des objets Connection, mais doit seulement pouvoir les obtenir à l'aide d'une méthode static dans ConnectionManager. Lorsque le ConnectionManager manque d'objets, il retourne une référence null. Testez la classe dans main( ).
11. Créez le fichier suivant dans le répertoire c05/local (supposé être dans votre CLASSPATH):

// c05:local:PackagedClass.java
package c05.local;
class PackagedClass {
    public PackagedClass() {
        System.out.println("Creating a packaged class");
    }
}

Créez ensuite le fichier suivant dans un répertoire autre que c05 :

// c05:foreign:Foreign.java
package c05.foreign;
import c05.local.*;
public class Foreign {
    public static void main (String[] args) {
        PackagedClass pc = new PackagedClass();
    }
}

Expliquez pourquoi le compilateur génère une erreur. Le fait de mettre la classe Foreign dans le package c05.local changerait-il quelque chose ?