Pourquoi les packages et les modules sont des concepts distincts dans Java 9?

Java 9 aura des modules en plus des packages. Habituellement, les langues ont l'une ou l'autre. Et la plupart des programmeurs perçoivent deux termes comme des synonymes. Les modules sont construits sur des packages, les traitant comme des primitives. Le motif composite suggère de traiter les primitives et les composites de manière uniforme. Sinon, de mauvaises choses se produiront. Par exemple, regardez le projet Valhalla, où ils essaient de moderniser le supertype commun pour les types primitifs (valeur) et de référence.

Les modules et les packages représentent-ils des notions sémantiquement distinctes? Cela signifie qu'il est judicieux d'avoir les deux pour n'importe quelle langue (séparation des préoccupations). Ou Java doit-il avoir les deux en hommage à la rétrocompatibilité?

Pourquoi introduire un nouveau concept au lieu d'en augmenter un existant?

JSR 376 : "Système de module de plate-forme Java" implémenté dans le projet Jigsaw .

Selon SOTMS

Un module est une collection nommée et auto-descriptive de code et de données. Son code est organisé comme un ensemble de packages contenant des types, c'est-à-dire des classes et des interfaces Java; ses données comprennent des ressources et d'autres types d'informations statiques.

JLS évite soigneusement de définir ce qu'est un package . De Wikipédia :

Un package Java est une technique pour organiser les classes Java en espaces de noms similaires aux modules de Modula, fournissant une programmation modulaire en Java.

Je sais que citer Wikipédia est une mauvaise pratique, mais cela reflète une compréhension commune. Dès l' entrée sur la programmation modulaire:

Le terme package est parfois utilisé à la place de module (comme dans Dart, Go ou Java). Dans d'autres implémentations, il s'agit d'un concept distinct; en Python, un package est une collection de modules, tandis que dans le prochain Java 9, l'introduction du nouveau concept de module (une collection de packages avec un contrôle d'accès amélioré) est prévue.

Le concept d'un module est différent de l'instanciation de ce concept.

Java a toujours eu des modules. Une méthode est un module, ainsi qu'une classe et un package. Un module est une unité d'organisation dans laquelle les détails internes sont cachés et qui communique avec d'autres modules via des contrats convenus. Par exemple, une méthode est un module car elle a des internes cachés (le code et les variables locales) et un contrat (les paramètres et le type de retour). Les modules peuvent être composés de modules de niveau inférieur, par exemple les classes contiennent des méthodes.

Ce qui manque dans le noyau Java (pré-9) est un module déployable . Tous les types de modules ci-dessus ne sont pas des unités déployables qui peuvent être copiées. Java a un artefact déployable appelé fichier JAR, mais ce ne sont pas des modules car ils n'ont ni encapsulation ni contrat: au moment de l'exécution, les fichiers JAR disparaissent, tous fusionnant dans un seul "chemin de classe".

OSGi a résolu le manque de modules déployables en 1998 avec le concept de «bundle». Il s'agit physiquement de fichiers JAR et ils contiennent des packages, mais OSGi définit des métadonnées supplémentaires ainsi qu'un système d'exécution pour prendre en charge l'encapsulation et les contrats à ce niveau.

Java 9 résout le manque de modules déployables d'une manière similaire à OSGi. On peut dire que cela était complètement inutile car OSGi existe et fonctionne, mais c'est une toute autre discussion ...

Malheureusement, Java 9 brouille les eaux en nommant le nouveau concept de module juste un "module". Cela ne signifie pas que les méthodes, les classes et les packages cessent d'être des modules! Un «module» J9 n'est qu'une autre instanciation du concept de module . Comme les bundles OSGi, les modules J9 sont constitués de packages et ce sont des artefacts physiques (généralement des fichiers JAR à nouveau) qui peuvent être copiés. Le système d'exécution les comprend et les réifie.

Résumé: oui les modules et packages J9 sont des notions sémantiquement distinctes. Évidemment, Java doit conserver son concept de package existant pour une compatibilité descendante. Notez que le mot «package» est utilisé très différemment en Java que dans d'autres langages ou dans des systèmes de gestion de packages comme RPM. Les nouveaux modules J9 (et les bundles OSGi) ressemblent beaucoup plus aux packages RPM que les packages Java ne l'ont jamais été.

Permettez-moi de risquer une réponse, bien que cela puisse être en grande partie des hypothèses / des cheveux coupants / des diatribes, etc.

S'agit-il de la même chose? Eh bien, oui ^_et non

De cet article JavaWorld sur "Modularité dans Java 9" :

Les packages comme solution modulaire

Les packages tentent d'ajouter un niveau d'abstraction au paysage de programmation Java. Ils fournissent des installations pour des espaces de noms de codage et des contextes de configuration uniques. Malheureusement, cependant, les conventions de package sont facilement contournées, ce qui conduit fréquemment à un environnement de couplages dangereux au moment de la compilation.

Comme l'indique @ user2418306 (OP) , "les modules sont des packages bien faits " . Les modules et les packages en Java (à partir de Java 9, évidemment) sont (comme OP le demande) sémantiquement la même chose. Autrement dit, ce sont des collections de bytecode JVM précompilé, avec d'autres métadonnées - essentiellement , ce sont des bibliothèques .

Eh bien, quelle est la différence?

Cependant, la différence réside dans les métadonnées à l'intérieur de chacune d'elles. Les packagemanifestes Java ou les manifestes JAR ne sont pas souvent maintenus par les développeurs de bibliothèques, et ils ne fournissent aucun contrat sûr quant à ce que le JAR / package fournit. Comme expliqué ici (article JavaWorld à nouveau) :

Les fichiers JAR ne sont-ils pas suffisamment modulaires?

Les fichiers JAR et l'environnement de déploiement dans lequel ils opèrent améliorent considérablement les nombreuses conventions de déploiement héritées autrement disponibles. Mais les fichiers JAR n'ont pas d'unicité intrinsèque, à part un numéro de version rarement utilisé, qui est caché dans un manifeste .jar. Le fichier JAR et le manifeste facultatif ne sont pas utilisés comme conventions de modularité dans l'environnement d'exécution Java. Ainsi, les noms de package des classes dans le fichier et leur participation à un chemin de classe sont les seules parties de la structure JAR qui confèrent une modularité à l'environnement d'exécution.

Une diatribe sur d'autres langues / environnements, etc.

Un autre domaine abordé dans cet article concerne les systèmes tels que Maven , qui gèrent les dépendances pour vous dans le cadre du processus de génération. De cette page sur le site Apache Maven :

Gestion des dépendances:

Maven encourage l'utilisation d'un référentiel central des fichiers JAR et autres dépendances. Maven est livré avec un mécanisme que les clients de votre projet peuvent utiliser pour télécharger les fichiers JAR nécessaires à la construction de votre projet à partir d'un référentiel JAR central, tout comme le CPAN de Perl. Cela permet aux utilisateurs de Maven de réutiliser les fichiers JAR d'un projet à l'autre et encourage la communication entre les projets pour garantir le traitement des problèmes de compatibilité descendante.

Maintenant, pour parler de l'avenir comme si j'y étais

Comme cette page l'a mentionné, d'autres langues (comme Perl) ont des référentiels de packages (comme CPAN ). C'est une tendance à la hausse (je dis parce que j'en ai envie, sans aucune preuve catégorique), au cours de la dernière décennie environ. Des outils tels que les gemmes de Ruby , PyPi de Python et le gestionnaire de packages Node ( npm) s'appuient sur cela pour fournir un moyen cohérent de configurer un environnement (développement, construction, test ou exécution, etc.) avec les bonnes choses (packages, modules, gemmes, gizmo, etc.). Une idée (je me sens) a été « emprunté » des systèmes de distribution Linux® tels que Debian apt , de RedHatrpm, etc. (Bien que, évidemment, a évolué au moins une génération, et a rendu ces choses plus agréables.)

Java modules , bien qu'ils ne correspondent pas nécessairement tout ce que vous ne pouvez pas le faire déjà, faire l' outillage pour les dépendances / gestion des paquets et des environnements de construction automatisés tout MUCH plus facile. Que cela rende les modules «meilleurs», je refuse de le dire. : P