Fractionner les paquets en java

Question

OSGi a un problème avec les packages divisés, c’est-à-dire le même package mais hébergés dans plusieurs bundles.

Existe-t-il des cas où le fractionnement de packages peut poser problème en Java pur (sans OSGi)?

Juste curieux.

Answer 1

Pour OSGi, les packages de différents bundles diffèrent, quel que soit leur nom, car chaque bundle utilise son propre chargeur de classes. Ce n’est pas un problème mais une fonctionnalité, pour assurer l’encapsulation des paquets.

En clair, cela ne pose donc normalement pas de problème pour Java, à moins que vous ne commenciez à utiliser un framework qui utilise des chargeurs de classes. C'est généralement le cas lorsque des composants sont chargés.

Answer 2

D'où proviennent les packages fractionnés

Les packages fractionnés (sous OSGi) se produisent lorsque l'en-tête de manifeste Require-Bundle est utilisé (tel qu'il est, je crois, dans les manifestes d'Eclipse). Require-Bundle nomme les autres ensembles utilisés pour la recherche de classes (si le package n'est pas Importé éd). La recherche est effectuée avant que le propre chemin de classes des ensembles ne soit recherché. Cela permet de charger les classes d’un seul package à partir des exportations de multiples ensembles (probablement des fichiers JAR distincts).

La section 3.13 de la spécification OSGi (4.1) décrit Require-Bundle et comporte une longue liste de conséquences (inattendues) de l'utilisation de cet en-tête (cet en-tête doit-il être obsolète?), dont une section est consacré aux packages fractionnés . Certaines de ces conséquences sont bizarres (et plutôt spécifiques à OSGi), mais la plupart sont évitées si vous comprenez une chose:

• si une classe (dans un package) est fournie par plusieurs ensembles, vous avez alors des problèmes.

Si les pièces du paquet sont disjointes, alors tout devrait aller bien, sauf que vous pourriez ne pas avoir les classes visibles et que les membres de visibilité du paquet peuvent sembler être privés s'ils sont vus depuis un " incorrect " partie d'un package fractionné.

[C’est bien sûr trop simple. Plusieurs versions de packages peuvent être installées & # 8212; mais du point de vue de l’application à tout moment , toutes les classes d’un package doivent provenir d’un module unique.]

Que se passe-t-il dans 'Java standard'

En Java standard, sans chargeurs de classes sophistiqués, vous avez un chemin de classes et l'ordre de recherche des jars (et des répertoires) des classes à charger est fixe et bien défini: ce que vous obtenez est ce que vous obtenez. (Mais alors, nous abandonnons la modularité gérable.)

Bien sûr, vous pouvez avoir des packages fractionnés, c’est assez courant en fait et cela indique une faible modularité. Les symptômes peuvent être des erreurs obscures de compilation / génération, mais dans le cas d'implémentations de classes multiples (une surplombe le reste d'un chemin de classe), il produit le plus souvent un comportement obscur à l'exécution, dû à une sémantique légèrement différente .

Si vous êtes chanceux , vous finissez par regarder le mauvais code sans vous en rendre compte et en vous posant la question, mais comment cela peut-il se faire. que ? "
Si vous êtes malchanceux , vous regardez le bon code et vous demandez exactement la même chose & # 8212; car quelque chose le reste produisait des réponses inattendues.

Cela n’est pas totalement différent du vieil adage de la base de données: "Si vous enregistrez la même information à deux endroits, il ne sera bientôt plus le même". Notre problème est que "très bientôt" n'est pas normalement assez tôt.

Answer 3

La division des paquets entre les bocaux n’est probablement pas une bonne idée. Je suggère de sceller tous les colis contenus dans des pots (insérez "Sealed: true" dans la section principale du manifeste). Les colis scellés ne peuvent pas être divisés entre des pots.

Dans le cas de OSGi, les classes portant le même nom de package mais un chargeur de classes différent sont traitées comme si elles se trouvaient dans des packages différents.

Answer 4

Vous obtiendrez une mauvaise erreur d'exécution si vous avez des classes dans le même package et que certaines sont dans un fichier JAR signé, tandis que d'autres ne le sont pas.

Answer 5

Demandez-vous parce que le package en question est le vôtre, pas du code tiers?

Un exemple simple serait une application Web avec des couches de service et de persistance sous forme de bundles OSGi distincts. Les interfaces de persistance devraient être partagées par les deux ensembles.

Si j'ai correctement interprété votre question, la solution serait-elle de créer un fichier JAR scellé contenant les interfaces partagées et de l'intégrer aux deux ensembles?

Je ne veux pas essayer de détourner le fil. Je demande des éclaircissements et une meilleure compréhension de la part de ceux qui auraient pu en faire plus avec OSGi à ce jour.