Chargement de classes et de ressources dans Java 9

Question

J'ai lu cet article sur InfoQ citant Reinhold:

Les développeurs peuvent toujours utiliser la classe Java chemin en Java 9 pour le Java l'exécution pour la recherche de classes et les fichiers de ressources. C'est juste que avec Java 9 modules, les développeurs n'ont plus besoin du chemin de classe.

Alors maintenant ma question est: quelle est la bonne Java 9 chemin pour accomplir les tâches énumérées ci-dessus? Comment voulez-vous charger dynamiquement, par exemple, une image (à court de jongler avec des chemins relatifs)?

Encore plus intéressant, comment pourrait-on vérifier si une classe est disponible et de prendre une décision de manière dynamique (p. ex. vérifier si Jackson est disponible et, si oui, l'utilisez pour la sérialisation JSON et si ne pas utiliser autre chose)?

L'article mentionne aussi le Printemps de Démarrage déjà supportant Java 9, et au Printemps de Démarrage n'a décidément beaucoup de chargement dynamique. Alors peut-être que quelqu'un connaît la priece de code à partir du Printemps que je peux regarder?

Answer 1

Tout d'abord, pour régler les pendules à l'heure, j'ai n'ai ni dit ni écrit, le texte cité ci-dessus. Je n'avais jamais pu le mettre de cette façon. C'est tout simplement bâclée les rapports de la part des publications concernées.

La chose la plus importante à comprendre au sujet de chargement de classe et de ressources de recherche en Java 9, c'est que, à un niveau fondamental, ils n'ont pas changé. Vous pouvez rechercher des classes et des ressources de la même manière que vous avez toujours ont, en invoquant Class::forName et les divers getResource*méthodes dans l' Class et ClassLoader classes, indépendamment du fait que votre code est chargé à partir de la classe de chemin ou le chemin d'accès du module. Il y a encore trois construit-dans la catégorie des chargeurs, tout comme il y avait dans le JDK 1.2, et ils ont l' délégation pour les relations. Beaucoup de code existant donc juste œuvres, out-of-the-box.

Il existe quelques nuances, comme indiqué dans la PEC 261: Le type de béton de la classe intégrée des chargeurs a changé, et certaines classes anciennement chargé par la classe de bootstrap loader sont maintenant chargés par la plate-forme de classe chargeur pour améliorer la sécurité. Code existant qui suppose qu'une construit-dans la classe loader est un URLClassLoader, ou qu'une classe est chargée par la classe de bootstrap loader, peuvent donc nécessiter des ajustements mineurs.

Une dernière différence importante est que les non-classe-ressources de fichiers dans un module sont encapsulés par défaut, et donc ne se trouve pas à l'extérieur le module à moins que leur efficacité est open. Pour charger les ressources à partir de votre propre module, il est préférable d'utiliser le ressources-méthodes de recherche en Class ou Module, qui peut trouver de tout ressource dans votre module, plutôt que ceux en ClassLoader, ce qui peut localiser uniquement non-classe-fichier de ressources dans l' open paquets d'un module.

Answer 2

[Edit: cette réponse a été rédigée à une Marque de réponse faisant autorité. J'ai révisé la mine de fournir un exemple simple, disponibles sur GitHub.]

Par cette vidéo, le chargement des classes en Java 9 est inchangé.

Comme un exemple, disons que nous avons:

• un example.jar qui contient une image dans le paquet net.codetojoy.example.resources
• pour renforcer le pot, net.codetojoy.example.Composer est public (et exportés, le cas échéant)
• un simple App de la classe qui utilise example.jar comme une bibliothèque et tente de charger l'image à partir d'elle

Le code en App:

static InputStream getResourceAsStream(String resource) 
    throws Exception {

    // Load net/codetojoy/example/resource/image.jpg
    // Assume net.codetojoy.example.Composer is public/exported
    // resource is 'resource/image.jpg'

    InputStream result = Composer.class.getResourceAsStream(resource);

    return result;
}   

Voici quelques cas pour example.jar dans le JDK 9:

À L'Ancienne, Non Modulaire Jar

Si example.jar n'est pas un module, le code fonctionne, tout simplement. Chargement de classe est inchangé.

Modulaire Pot Avec De L'Ouvrir Paquet

Dans ce cas, c'est l' module-info.java le fichier:

module net.codetojoy.example {
    // export the Composer class
    exports net.codetojoy.example;

    // image is available
    opens net.codetojoy.example.resources;
}

Dans ce cas, l'image peut être chargé par le client, parce que le paquet est ouvert.

Modulaire Pot Sans Ouvrir L'Emballage

Dans ce cas, module-info.java est:

module net.codetojoy.example {
    // export the Composer class
    exports net.codetojoy.example;

    // package not opened: image not available
    // opens net.codetojoy.example.resources;
}

Dans ce cas, l'image ne peut pas être chargé, en raison de la forte encapsulation: le module est la protection de l'image en n'ouvrant pas le paquet.

Source complet ici sur GitHub.