Pourquoi Sun invente-t-il un autre système de modules alors que tout le monde a standardisé OSGi?

Question

Sun met beaucoup d'efforts derrière la modularisation du JDK sous la forme de Jigsaw, et insinuant que ce devrait être le format de module de choix pour les autres développeurs Java. Le seul joueur notable qui utilise ceci est NetBeans (et les applications dérivées). D'autre part, l'industrie s'est standardisée autour de OSGi, tous les principaux fournisseurs d'applications basant leurs temps d'exécution sur la plate-forme de modules, même Glassfish de Sun. Il y a même un port de NetBeans pour utiliser OSGi comme système de module au lieu de modules propres à NetBeans. Même Maven travaille à devenir une exécution OSGi. Est-il juste NIH, licence, ou une autre raison?

Answer 1

Excellente question. Je crois comprendre que dans certaines régions, OSGi va bien au-delà de ce qui est nécessaire pour les modules JVM (avec toute la complexité correspondante), alors que dans d'autres domaines, il ne va pas assez loin. Il y a donc beaucoup de chevauchement entre eux, mais peut-être pas assez.

See this blog entry

Answer 2

Citant http://blogs.oracle.com/mr/entry/jigsaw:

OSGi est pas du tout intégré au langage Java, cependant, après avoir été construit au sommet de la plate-forme Java SE plutôt que de l'intérieur.

Ce dernier problème peut être corrigé. Sun envisage maintenant de travailler directement avec l'OSGi Alliance afin qu'une future version du cadre OSGi peut pleinement exploiter les fonctionnalités de JSR 294 et ainsi obtenir une meilleure intégration avec la langue.

(...)

Si et quand une future version de la plate-forme Java SE comprend un système de module fi spécifique puis Sun fournira un moyen de migrer modules Jigsaw jusqu'à cette norme. En attendant, nous chercherons activement des moyens de d'interopérer avec d'autres systèmes du module , et en particulier avec OSGi.

Answer 3

Une caractéristique est manquant dans OSGi. Il ne prend pas en charge les modules qui sont des sous-ensembles de packages. Le export is done on the package level.

Les modules de sous-ensemble de paquetages sont la seule façon de couper le nœud gordien des dépendances JDK. Et un bon indice pourquoi vous devriez garder votre code propre de dépendances circulaires.

Over the years, however, this style of development can lead to unexpected connections between APIs—and between their implementations—leading in turn to increased startup time and memory footprint. A trivial command-line “Hello, world!” program, e.g., now loads and initializes over 300 separate classes, taking around 100ms on a recent desktop machine despite yet more heroic engineering efforts such as class-data sharing. The situation is even worse, of course, for larger applications.

Edit: J'étais mal. OSGi does support split packages.

Answer 4

La raison d'être du projet Jigsaw et de sa relation avec OSGi a été soulignée par l'équipe de Jigsaw au Java Posse Podcast 259.

Ces projets ne se chevauchent pas entièrement et l'introduction de Jigsaw ne sonnera pas le glas de l'OSGi - la portée d'OSGi va au-delà de tout ce que Jigsaw tentera de faire. Jigsaw a beaucoup plus à offrir que l'équipe OSGi n'est en mesure de fournir (changements de langue, de classe et de mise en œuvre de la JVM). La conception d'OSGi est basée sur la conception actuelle de la JVM - les changements apportés à la JVM bénéficieront à tout le monde.

Au moins, c'est ma prise de what I've read.

Answer 5

Consultez le JavaPosse interview with Mark Reinhold sur le sujet.