Discussion :

[patou21]

Bonjour,

Je suis en train de créer une API que je dois fournir à des clients.

Il y a certaines classes de cette API que je souhaiterais cacher à ceux qui l'utiliseront j'ai donc mis une visibilité package à ces classes.

Malheureusement, je me rends compte que quand j'utilise le même nom de package que celui de l'API pour accéder à celui-ci j'ai accès à toutes les classes que je souhaitais cacher.

Existe-t-il une possibilité de protéger cela ou ce n'est pas possible ?

Merci beaucoup de votre réponse

[Uther]

Non c'est le principe de la visibilité package d'être visible depuis les fichiers du même paquage.

Normalement une API ne devrait pas se trouver dans le même package que l'application qui l'utilise. Le nom de pacquage doit être choisi de manière judicieuse pour éviter des colisions de nom involontaires. De plus pour ne pas encourager cela il faut éviter de générer la documentation de l'API sur les élément de visibilité private et package.

Un programmeur pas trop bête sait qu'il est censé laisser une API dans son propre package et ne pas programmer dedans. S'il le fait c'est en connaissance de cause.

[slim_java]

Le nom de pacquage doit être choisi de manière judicieuse pour éviter des colisions de nom involontaires.

malheureusement c'est pas toujours le cas pour les pacquages standards

[Uther]

Normalement les noms de pacquage de l'api java sont bien définis, dans java et javax, ou en utilisant des nom de domaines inversés, donc il n'y a pas d'ambiguité possible.

Si tes programmes sont dans des pacquages java.xxx ou javax.xxx, il faut vraiment vouloir se chercher des emmerdes.

En général utiliser le système des noms de dommaine inversé pour les paquage permet de manière assez sure d'éviter le genre de problème dont parle patou21. Si l'utilisateur de l'API utilise un nom de domaine qui n'est pas le sien comme nom de pacquage, c'est qu'il fait ça en connaissance de cause.

[tchize_]

précision qui a son importance. Quand on parle de visibilité "private" ou "protected", ca s'entends au niveau du design de l'application et des règles du language. Ca n'a rien a voir avec un protection contre la copie ou le piratage ou avec la sécurité. Il est toujours possible de contourner la limitation, par exemple, en créant des classes intermédiare dans le meme package qui exposent les données protégées. Mais comme si bien dit, le programmeur le fait alors en connaissance de cause.

[slim_java]

je pense que l'utilisation des mots clé "private" ,"public".. et la gestion de visibilité en général n'a un sens que lors de developpoment des composant java beans REUTILISABLE.

[Uther]

Réduire la visibilité est certes indispensable quand on a des composant dont juste une partie doit être accessible a l'utilisateur final.
Mais quand un projet grossi et/ou est manipulé par de nombreuses personnes, il devient important de travailler avec de objets ayant des règles claires, même s'il n'ont pas pour vocation d'être réutilisables. Si tous les champs d'un objet peuvent être modifiés sans contraintes par n'importe quelle classe, on risque de finir avec des comportements inattendus.

[slim_java]

je rajoute bien évidemment

et quand un projet grossi et/ou est manipulé par de nombreuses personnes.

[adiGuba]

Salut,



Il y a aussi la possibilité de scellé les package de ton jar.
Pour cela il faut rajouter pour chacun de tes packages les lignes suivantes dans le manifest (avec une ligne vide avant et après) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Name: com/tonpackage/
Sealed: true

La JVM vérifiera alors que toutes les classes du packages com.tonpackage viennent bien du même fichier *.jar, et génèrera une erreur si ce n'est pas le cas...


a++