OSGi, Java Modularité et scie sauteuse
Donc, hier matin, je n'avais aucune idée de ce qu'était OSGi. OSGi était juste un mot à la mode que je n'arrêtais pas de voir recadrer encore et encore, et j'ai donc finalement mis de côté un peu de temps pour le rafraîchir.
Cela semble en fait assez cool, donc je voudrais commencer par dire (pour mémoire) que je ne suis pas anti-OSGi en aucune façon, et ce n'est pas non plus une question de "dénigrement d'OSGi".
À la fin de la journée, il semble que OSGi a - essentiellement - adressé JSR 277 on Java Modularity, qui a reconnu qu'il y a des lacunes avec le JAR spécification de fichier qui peut conduire à des problèmes de résolution d'espace de nommage et de chargement de classe dans certains cas de coin. OSGi fait également beaucoup d'autres choses vraiment cool, mais d'après ce que je peux vérifier, c'est son plus gros tirage (ou l'un d'eux).
Pour moi - en tant que développeur assez récent (quelques années maintenant) Java EE, il est absolument ahurissant que nous soyons en 2011 et vivions actuellement à l'ère de Java 7, et que ces problèmes de chargement de classe sont toujours présents; en particulier dans les environnements d'entreprise où un serveur d'applications peut contenir des centaines de fichiers JAR, la plupart d'entre eux dépendant de différentes versions les uns des autres et tous fonctionnant (plus ou moins) simultanément.
Ma question:
Aussi intéressé que je suis par OSGi, et autant que je veux commencer à l'apprendre pour voir où/si cela pourrait être utile à mes projets, je n'ai tout simplement pas le temps de m'asseoir et d'apprendre quelque chose d'aussi grand, Au moins maintenant.
Alors, que doivent faire les développeurs non OSGi lorsque ces problèmes surviennent? Que Java Des solutions (Oracle/Sun/JCP) existent-elles actuellement, le cas échéant? Pourquoi Jigsaw a-t-il été coupé de J7? Dans quelle mesure 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 plateforme Java?
Je suppose que ce que je demande ici, c'est une combinaison de panique, d'intrigue et d'un visage. Maintenant que je comprends enfin ce qu'est l'OSGi, je ne comprends tout simplement pas comment quelque chose comme Jigsaw a mis plus de 20 ans à se concrétiser, puis comment cela aurait pu être conservé à partir d'une version. Cela semble juste fondamental.
Et, en tant que développeur, je suis également curieux de savoir quelles sont mes solutions, sans OSGi.
En outre, Remarque : Je sais que ce n'est pas une question de type " pure programmation", mais avant certains vous avez le nez plié, je voulais dire (encore une fois, pour mémoire) que j'ai délibérément posé cette question à SO. C'est parce que je n'ai que le plus grand respect pour mes collègues SOers et je cherche une réponse au niveau architectural de certains des "Dieux de l'informatique" que je vois rôder ici chaque jour.
Mais, pour ceux d'entre vous qui absolument insistez qu'une question SO soit accompagnée d'un segment de code:
int x = 9;
(Merci à tous ceux qui peuvent peser sur ce truc OSGi/Jigsaw/classloader/namespace/JAR hell!)
Tout d'abord, comprenez que le cas d'utilisation principal de Jigsaw est de modulariser le JRE lui-même. Comme objectif secondaire, il offrira un système de modules qui peut être utilisé par d'autres bibliothèques et applications Java.
Ma position est que quelque chose comme Jigsaw est probablement nécessaire uniquement pour le JRE, mais qu'il créera beaucoup plus de problèmes qu'il ne prétend résoudre s'il est utilisé par d'autres Java bibliothèques ou applications.
Le JRE est un cas très difficile et spécial. Il a plus de 12 ans et est un effroyable gâchis, criblé de cycles de dépendance et de dépendances absurdes. En même temps, il est utilisé par environ 9 millions développeurs et probablement milliards de systèmes en cours d'exécution. Par conséquent, vous ne pouvez absolument pas refactoriser le JRE si ce refactoring crée des changements de rupture.
OSGi est un système de modules qui vous aide (ou même vous oblige à) créer un logiciel modulaire. Vous ne pouvez pas simplement saupoudrer la modularité au-dessus d'une base de code non modulaire existante. Transformer une base de code non modulaire en une base modulaire nécessite inévitablement une refactorisation: déplacer les classes dans le package correct, remplacer l'instanciation directe par l'utilisation de services découplés, etc.
Cela rend difficile l'application directe d'OSGi à la base de code JRE, mais nous avons toujours besoin de diviser le JRE en morceaux ou "modules" séparés afin que des versions réduites du JRE puissent être livrées.
Je considère donc Jigsaw comme une sorte de "mesure extrême" pour garder le code JRE en vie tout en le divisant. Il fait pas aider le code à devenir plus modulaire, et je suis convaincu qu'il augmentera en fait la maintenance requise pour faire évoluer n'importe quelle bibliothèque ou application qui l'utilise.
Enfin: OSGi existe alors que Jigsaw n'existe pas encore et peut ne jamais exister. 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.
C'est simple, si vous voulez faire du vrai développement basé sur des composants dans Java aujourd'hui, alors OSGi est le seul jeu en ville.
À mon avis, Jigsaw est une combinaison d'un compromis entre ce qui est faisable dans le JDK et les mauvaises relations antérieures entre Sun et les gars d'OSGi. Peut-être qu'il sera 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 de classe car un certain nombre de bibliothèques bien connues (vous regardant, Hibernate) ont fait des hypothèses sur la visibilité de la classe qui ne sont plus valides à l'intérieur d'OSGi.
J'aime OSGi, mais je n'essaierais pas de l'adapter à un système existant. J'évaluerais également les avantages et les inconvénients en termes de développement sur le terrain - je recommanderais de regarder les produits Apache ou Eclipse qui simplifient la vie d'OSGi et de ne pas tout faire vous-même.
Si vous ne faites pas OSGi, alors vous n'avez pas de chance si vous avez trouvé un système qui a des dépendances sur différentes versions de la même bibliothèque - tout ce que vous pouvez faire est d'essayer d'éviter le problème, même si vous avez besoin de plusieurs versions d'un bibliothèque me semble être une "odeur" d'architecture.
J'adore votre utilisation de l'expression "cas d'angle" pour décrire la situation actuelle.
il y a des lacunes dans la spécification du fichier JAR qui peuvent entraîner des problèmes de résolution d'espace de noms et de chargement de classe dans certains cas d'angle
Quoi qu'il en soit, depuis de nombreuses années, je m'intéresse aux outils et aux techniques qui soutiennent la création et, mieux encore, l'application d'un code plus propre, plus découplé, plus cohérent et plus maintenable que ce qui aurait probablement été le résultat sans eux. Test Driven Design et Junit étaient une telle combinaison.
Après avoir passé quelques mois à déplacer une partie substantielle de notre base de code vers OSGi, je dirais que OSGi est un outil encore meilleur à cet égard. Et c'est vraiment une raison suffisante pour passer à OSGi. À long terme, cela vous fera économiser beaucoup d'argent.
Et, en bonus, cela vous donnera la chance de faire beaucoup de trucs sympas. Imaginez, lors d'une démo, la mise à niveau transparente du module d'authentification, sans perte de trafic, pour prendre en charge OAuth ... c'est tout à coup une joie de créer des trucs!