Je comprends les avantages du Java Platform Module System (JPMS) pour les grandes applications, mais y a-t-il une raison de transformer une petite bibliothèque ou application en un (unique) module? Si tel est le cas, les Modular Jar Files sont-ils le meilleur moyen d’y parvenir? , ou l'approche normale est-elle préférée?

À l'avenir, y aura-t-il des implications en termes de performances pour les programmes modulaires v. Classpath?

6
kantianethics 13 août 2017 à 00:47

2 réponses

Si tel est le cas, les fichiers Jar modulaires sont-ils le meilleur moyen d'y parvenir ou l'approche normale est-elle préférée?

Je ne suis pas sûr de ce que vous entendez par "l'approche normale" - les JAR modulaires sont «l'approche normale» pour créer des artefacts pour lesquels le système de modules créera un module.

[Y a-t-il une raison de transformer une petite bibliothèque ou une application en un (unique) module?

Oui, quelques-uns:

  • Les développeurs qui créent une application modulaire ou utilisent une bibliothèque modulaire bénéficient de fiable configuration, où ils ne peuvent lancer leur application que si toutes les dépendances sont présentes - c'est un avantage quelle que soit la taille de l'application / bibliothèque.

  • En tant que concepteur de bibliothèque, vous pouvez masquer les éléments internes. Alors que encapsulation forte n'est efficace que si votre JAR est placé sur le chemin du module, le descripteur de module documente toujours votre intention dans le code et vous permet de modifier votre code de manière plus sans scrupules. Les développeurs d'applications en bénéficient également car ils ne peuvent plus dépendre accidentellement de détails d'implémentation non pris en charge.

  • Même dans les petites applications et bibliothèques, les services peuvent être utilisés pour découpler différents aspects de la fonctionnalité et rendre le code plus facilement extensible.

  • Seuls les modules "réels" (par opposition aux modules automatiques) peuvent être inclus dans une image d'exécution par jlink. Ne pas fournir un JAR modulaire prive vos utilisateurs d'une bibliothèque de cette possibilité.

Notez également que vous ne savez jamais quelle petite application ou bibliothèque pourrait devenir quelque chose de plus grand. :)

À l'avenir, y aura-t-il des implications en termes de performances pour les programmes modulaires v. Classpath?

Bien que la construction du graphique du module et la vérification des modules coûtent du temps, le système de modules devrait le rattraper avec une stratégie de chargement de classe améliorée: il enregistre pour chaque paquet quel module l'exporte et charge les types de ce paquet directement à partir de ce module au lieu d'avoir à analyser le module. chemin de classe entier. de toute façon, je ne pense pas que cela devrait être un facteur décisif.

3
Nicolai 1 déc. 2017 à 12:04

J'ai trouvé ce lien informatif
http://www.javaworld.com/ article / 2878952 / plateforme-java / modularité-en-java-9.html

Les fichiers JAR ne sont-ils pas suffisamment modulaires?

Les fichiers JAR et l'environnement de déploiement dans lequel ils fonctionnent améliorent considérablement les nombreuses conventions de déploiement héritées autrement disponibles. Mais les fichiers JAR n'ont aucune 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 de la modularité à l'environnement d'exécution.

En bref, les JAR sont une bonne tentative de modularisation, mais ils ne remplissent pas toutes les exigences d'un environnement véritablement modulaire. Les frameworks et plates-formes comme Spring et OSGi utilisent des modèles et des améliorations de la spécification JAR pour fournir des environnements permettant de créer des systèmes très performants et modulaires. Avec le temps, cependant, même ces outils succomberont à un effet secondaire très malheureux de l'enfer JAR de spécification JAR!

Chemin de classe / enfer JAR

Lorsque l'environnement d'exécution Java autorise des mécanismes de chargement JAR arbitrairement complexes, les développeurs savent qu'ils sont dans l'enfer du chemin de classe ou de l'enfer JAR. Un certain nombre de configurations peuvent conduire à cette condition.

Tout d'abord, considérons une situation dans laquelle un développeur d'application Java fournit une version mise à jour de l'application et l'a empaquetée dans un fichier JAR portant exactement le même nom que l'ancienne version. L'environnement d'exécution Java ne fournit aucune fonctionnalité de validation pour déterminer le fichier JAR correct. L'environnement d'exécution chargera simplement les classes à partir du fichier JAR qu'il trouve en premier ou qui satisfait l'une des nombreuses règles de chemin de classe. Cela conduit au mieux à un comportement inattendu.

Une autre instance de l'enfer JAR survient lorsque deux ou plusieurs applications ou processus dépendent de versions différentes d'une bibliothèque tierce. À l'aide des fonctions de chargement de classe standard, une seule version de la bibliothèque tierce sera disponible au moment de l'exécution, ce qui entraînera des erreurs dans au moins une application ou un processus.

Un système de modules Java complet et efficace devrait faciliter la séparation du code en modules distincts, faciles à comprendre et faiblement couplés. Les dépendances doivent être clairement spécifiées et strictement appliquées. Des installations devraient être disponibles pour permettre la mise à niveau des modules sans avoir un effet négatif sur les autres modules. Un environnement d'exécution modulaire doit permettre des configurations spécifiques à un domaine particulier ou à un marché vertical, réduisant ainsi le temps de démarrage et l'empreinte système de l'environnement.

Solutions de modularité pour Java

Outre les fonctionnalités de modularité mentionnées jusqu'à présent, les efforts récents en ajoutent quelques-uns. Les fonctionnalités suivantes sont destinées à optimiser les performances et à permettre l'extension de l'environnement d'exécution:

Code source segmenté: Code source séparé en segments distincts et mis en cache, chacun contient un type spécifique de code compilé. Dont les objectifs comprennent ignorer le code non-méthode pendant les balayages de mémoire, les constructions incrémentielles, et une meilleure gestion de la mémoire.

Application lors de la construction: Constructions de langage pour appliquer les espaces de noms, gestion des versions, dépendances et autres.

Installations de déploiement: Assistance pour déployer des environnements d'exécution évolutifs en fonction des besoins spécifiques, comme ceux d'un environnement d'appareil mobile

0
Noman Khan 19 août 2017 à 07:27