Hiérarchies apparentes de paquets

Question

Dans ce poste http://java.sun.com/docs/books/tutorial/java/package/usepkgs.html

dans le paragraphe "Hiérarchies apparentes de paquets" est écrit :

"" À première vue, les paquets semblent être hiérarchisés, mais ils ne le sont pas. Par exemple, l'API Java comprend un paquetage java.awt, un paquetage java.awt.color, un paquetage java.awt.font, et beaucoup d'autres qui commencent par java.awt. Cependant, le paquetage java.awt.color, le paquetage java.awt.font et d'autres paquetages java.awt.xxxx ne sont pas inclus dans le paquetage java.awt. ""

mais si je désarticule rt.jar, je découvre que java.awt.color et java.awt.font sont mappés de manière hiérarchique : java/awt/cololor et java.awt.font. de manière hiérarchique : java/awt/color et java/awt/font alors est-ce que je comprends mal ou est-ce qu'il y a une erreur dans ce post ?

Cependant, est-il possible de créer des paquets non hiérarchisés ? des noms de paquets logiques qui ne correspondent pas à la structure d'un paquet physique ?

Answer 1

L'article auquel vous faites référence explique le point dans le paragraphe suivant. Les noms des paquets sont utilisés pour indiquer des relations aux yeux des programmeurs mais n'ont aucune relation aux yeux du compilateur. Comme l'explique l'article, l'importation de java.awt.* n'importera pas de classes dans java.awt.font il s'agit de paquets complètement séparés qui n'ont aucune relation hiérarchique dans le langage de programmation. Pour importer toutes les classes de java.awt.font vous devez importer java.awt.font.* et qui n'importe aucune classe du paquetage parent java.awt ou dans des paquets frères comme java.awt.color .

Ainsi, même s'il existe une relation hiérarchique apparente pour le programmeur, il n'y en a pas vraiment dans le langage. Pour accéder aux classes d'un paquetage donné, vous devez les importer depuis leur paquetage exact.

Si les paquets étaient réellement des hiérarchies, on pourrait imaginer que ce serait le cas. Cependant, la hiérarchie n'est là que pour organiser le code et indiquer aux programmeurs qu'un ensemble donné de paquets est destiné à être utilisé ensemble.

Answer 2

L'article poursuit

L'importation de java.awt.* importe tous les types de du paquet java.awt, mais il n'importe pas il n'importe pas java.awt.color, java.awt.font, ou tout autre paquets java.awt.xxxx.

Elle décrit donc simplement le comportement général de l'instruction d'importation : import package.* importe toutes les classes de package mais pas de classes de sous-paquets.

Oui, les fichiers de classe sont dans rt.jar, là où nous les attendons, il s'agit uniquement d'importer des classes dans des fichiers source java.

Modifier

Oui, le tutoriel ajoute un certain degré de confusion.

Essayez de comprendre un paquet comme une collection de classes qui partagent un espace de nom commun. java.awt est un espace de nom, java.lang et java.awt.color en est une autre. Et maintenant comprenez, que le java.awt et le java.awt.color Les espaces de noms ne sont pas liés. java.awt.color n'est pas un espace de nom "enfant" de java.awt . Et en effet, il n'y a pas de règle en Java qui oblige à mettre certaines classes dans certains paquets "enfants". S'il existait une hiérarchie, je m'attendrais à des règles telles que l'obligation de déclarer les implémentations dans un "espace de noms enfant" de l'interface, etc. Mais il n'y a pas de

Oui, le mappage actuel des espaces de noms aux systèmes de fichiers introduit une hiérarchie de dossiers, où la couleur est un dossier dans awt. C'est assez pratique, sinon nous aurions besoin d'un mappage entre l'espace de noms des paquets et l'emplacement physique des classes dans le système de fichiers. Maintenant, nous pouvons déterminer l'emplacement à partir de l'espace de noms du paquet. Et cela nous donne l'impression que cette hiérarchie est également vraie pour les espaces de noms des paquets.

Mais ce n'est pas le cas. Et c'est ce que le tutoriel veut dire.

(merci pour la question, j'ai appris et compris beaucoup de choses en réfléchissant à la réponse ;) )

Answer 3

Ce que le tutoriel signifie, c'est qu'il n'existe pas de concept de sous-paquet en Java. Un paquetage peut se trouver physiquement dans un sous-dossier du système de fichiers, mais cela ne signifie pas qu'il sera automatiquement inclus (cf. Réponse d'Andreas ).

Il ne donne pas non plus aux classes du paquet de niveau supérieur les droits d'accès aux classes privées du paquet (par défaut), comme on pourrait s'y attendre s'il existait une hiérarchie de paquets.

Answer 4

Le système de dénomination est hiérarchique, ainsi que le contenu des fichiers jar.

Cependant, il n'y a pas de lien entre java.awt et java.awt.color, c'est-à-dire que, par exemple, si vous déclarez une classe en tant que package private (sans modificateur) dans le package foo il sera accessible à partir de foo mais pas de foo.bar .

Answer 5

Pensez à la hiérarchie comme à un système de fichiers. En Java, les paquets sont comme des répertoires et les classes sont comme des fichiers. Les paquets sont destinés à contenir un ensemble de classes liées. Lorsque des groupes de paquets sont logiquement liés, ils peuvent être nommés de manière à apparaître comme un membre d'une hiérarchie plus large. En regardant l'exemple java.awt.* ci-dessus, je pourrais placer les classes pour AWT dans jar1. Il aurait la structure suivante :

jar-1
   \-java
       \-awt

Dans le répertoire awt, vous trouverez les classes et interfaces qui se déclarent membres du paquet java.awt.

Maintenant, je veux implémenter des polices pour l'awt mais je les ai mises dans un bocal séparé :

jar-2
  \-java
     \-awt
         \-fonts

Le répertoire des polices est l'endroit où se trouvent les classes et les interfaces pour les polices que j'ai créées pour awt.

Lorsque vous allez programmer en utilisant AWT et mes polices, vous devez d'abord inclure jar-1 et jar-2 dans votre CLASSPATH. Lorsque vous incluez les classes, vous n'obtenez aucune information sur la jarre dans laquelle le compilateur les a trouvées.

//this loads all classes in the java.awt directory 
//  which happen to come from jar-1
include java.awt.*  

Si vous voulez les polices,

//Load all classes in the java.awt.fonts directory
//  which happen to come from jar-2
include java.awt.fonts.*

Pour le compilateur et le runtime, la hiérarchie ressemble à un grand arbre. Cela ne signifie pas que les classes résident toutes physiquement au même endroit. Ceci étant dit, je dois faire deux remarques : 1) il n'est pas recommandé de séparer les paquets de la même hiérarchie dans des bocaux différents, car cela crée de la confusion et un casse-tête pour la maintenance, et 2) déclarer des paquets comme des extensions de la structure de paquets de quelqu'un d'autre est extrêmement mal vu, même si le compilateur vous laisse faire.