OSGi, modularité Java et Jigsaw

Question

Hier matin, je n'avais pas la moindre idée de ce qu'était OSGi. OSGi n'était qu'un mot à la mode qui revenait sans cesse, et j'ai fini par prendre le temps de m'y mettre.

En fait, cela semble plutôt cool, alors j'aimerais commencer par affirmer (pour le compte rendu) que je ne suis pas anti-OSGi à quelque égard que ce soit, et que ce n'est pas une question de "dénigrement de l'OSGi".

En fin de compte, il semble qu'OSGi ait - essentiellement - résolu les problèmes suivants JSR 277 sur la modularité de Java, qui a reconnu qu'il y a des lacunes dans le système de gestion de l'information. JAR qui peut conduire à des problèmes de résolution d'espace de nom et de chargement de classe dans certains cas particuliers. OSGi fait également beaucoup d'autres choses vraiment cool, mais d'après ce que je peux vérifier, c'est son plus grand avantage (ou l'un d'entre eux).

Pour moi, en tant que développeur Java EE relativement récent (quelques années maintenant), il est absolument stupéfiant que nous soyons en 2011 et que nous vivions actuellement à l'ère de Java 7, et que ces problèmes de chargement de classe soient toujours présents, en particulier dans les environnements d'entreprise où un serveur d'applications peut contenir des centaines de JAR, dont beaucoup dépendent de différentes versions les unes des autres et s'exécutent (plus ou moins) simultanément.

Ma question :

Bien que je sois intéressé par OSGi et que je veuille commencer à m'y intéresser pour voir si cela peut être utile à mes projets, je n'ai tout simplement pas le temps de m'asseoir et d'apprendre quelque chose d'aussi vaste, du moins pour le moment.

Que doivent donc faire les développeurs non-OSGi lorsque ces problèmes surviennent ? Quoi Java (Oracle/Sun/JCP) existent actuellement, le cas échéant ? Pourquoi Jigsaw a-t-il été supprimé de J7 ? La communauté est-elle sûre que Jigsaw sera implémenté l'année prochaine dans J8 ? Est-il possible d'obtenir Jigsaw pour votre projet même s'il ne fait pas encore partie de la plate-forme Java ?

Je suppose que ce que je demande ici est une combinaison de panique, d'intrigue et de facepalm. Maintenant que je comprends enfin ce qu'est OSGi, je ne "comprends" pas comment quelque chose comme Jigsaw a mis plus de 20 ans à se concrétiser, et comment il a pu être mis en boîte avant sa sortie. Cela semble fondamental.

Et, en tant que développeur, je suis également curieux de savoir quelles sont mes solutions, sans OSGi.

Aussi, Nota : Je sais que ce n'est pas un " programmation pure "Mais avant que certains d'entre vous ne prennent la grosse tête, je tiens à préciser (encore une fois, pour mémoire) que j'ai délibérément posé cette question sur SO. C'est parce que je n'ai rien d'autre que le plus grand respect pour mes collègues de SO et que je cherche une réponse de niveau architectural de la part de certains des "Dieux de l'informatique" que je vois rôder ici chaque jour.

Mais, pour ceux d'entre vous qui veulent absolument insister qu'une question de l'OS soit appuyée par un segment de code :

int x = 9;

(Merci à tous ceux qui peuvent nous éclairer sur cette histoire d'enfer OSGi/Jigsaw/classloader/namespace/JAR).

Answer 1

Il faut d'abord comprendre que le principal cas d'utilisation de Jigsaw est la modularisation du JRE lui-même. Comme objectif secondaire, il offrira un système de modules qui pourra être utilisé par d'autres bibliothèques et applications Java.

Ma position est la suivante quelque chose comme Jigsaw est probablement nécessaire pour le JRE uniquement, mais qu'il créera beaucoup plus de problèmes qu'il ne prétend en résoudre s'il est utilisé par d'autres bibliothèques ou applications Java.

Le JRE est un cas très difficile et particulier. Il a plus de 12 ans et est un désordre effrayant, criblé de cycles de dépendances et de dépendances absurdes. En même temps, il est utilisé par environ 9 millions les développeurs et probablement milliards d'euros des systèmes en fonctionnement. C'est pourquoi vous ne pouvez absolument pas remanier le JRE si ce remaniement entraîne des changements cassants.

OSGi est un système de modules qui vous aide (ou même forces pour) créer des logiciels qui sont modulaires. Vous ne pouvez pas simplement saupoudrer la modularité sur une base de code non modulaire existante. Transformer une base de code non modulaire en une base modulaire nécessite inévitablement un certain remaniement : déplacer les classes dans le bon paquetage, remplacer l'instanciation directe par l'utilisation de services découplés, et ainsi de suite.

Il est donc difficile d'appliquer OSGi directement à la base de code JRE, mais il est toujours nécessaire de diviser le JRE en morceaux distincts ou "modules" afin de pouvoir fournir des versions réduites du JRE.

Je considère donc Jigsaw comme une sorte de " mesure extrême "pour maintenir le code JRE en vie tout en le divisant. Il fait no aider le code à devenir plus modulaire, et je suis convaincu qu'il augmentera en fait la maintenance nécessaire pour faire évoluer toute bibliothèque ou application qui l'utilise.

Enfin : OSGi existe alors que Jigsaw n'existe pas encore et n'existera peut-être jamais. La communauté OSGi a 12 ans d'expérience dans le développement d'applications modulaires. Si vous êtes sérieusement intéressé par le développement d'applications modulaires, OSGi est le seul jeu en ville.

Answer 2

C'est simple, si vous voulez faire du vrai développement basé sur les composants en Java aujourd'hui, OSGi est le seul jeu en ville.

À mon avis, Jigsaw est une combinaison d'un compromis de ce qui est faisable dans le JDK et des mauvaises relations passées entre SUN et les gars d'OSGi. Peut-être sera-t-il livré avec Java 8, mais nous devons attendre et voir.

OSGi n'est pas une panacée si vous travaillez dans un environnement d'entreprise typique et vous devrez vous familiariser avec le fonctionnement du chargement des classes, car un certain nombre de bibliothèques bien connues (je vous regarde, Hibernate) faisaient des suppositions sur la visibilité des classes qui ne sont plus valables dans OSGi.

J'aime OSGi, mais je n'essaierais pas de l'adapter à un système existant. Je pèserais également le pour et le contre en termes de développement sur site vierge - je recommanderais de regarder les produits Apache ou Eclipse qui simplifient la vie pour OSGi et de ne pas tout faire soi-même.

Si vous n'utilisez pas OSGi, vous n'avez pas de chance si votre système dépend de différentes versions d'une même bibliothèque. Tout ce que vous pouvez faire est d'essayer d'éviter le problème, bien que le fait d'avoir besoin de plusieurs versions d'une bibliothèque me semble être une "odeur" d'architecture.

Answer 3

J'adore votre utilisation de l'expression "cas particuliers" pour décrire la situation actuelle.

la spécification des fichiers JAR présente des lacunes qui peuvent entraîner des problèmes de résolution d'espace de noms et de chargement de classes dans certains cas particuliers.

Quoi qu'il en soit, depuis de nombreuses années, je m'intéresse aux outils et techniques qui permettent de créer et, mieux encore, de faire respecter un code plus propre, plus découplé, plus cohérent et plus facile à maintenir que ce qui aurait probablement été le résultat sans eux. La conception pilotée par les tests et Junit étaient une telle combinaison.

Après avoir passé quelques mois à transférer une partie importante de notre base de code vers OSGi, je dirais qu'OSGi est un outil encore meilleur à cet égard. Et c'est vraiment une raison suffisante pour passer à OSGi. À long terme, cela vous permettra d'économiser beaucoup d'argent.

Et, en prime, ça te donnera l'occasion de faire plein de trucs sympas. Imaginez, au cours d'une démonstration, la mise à niveau transparente du module d'authentification, sans perte de trafic, pour prendre en charge OAuth ... c'est soudain une nouvelle joie de créer des choses !