Discussion :

[professeur shadoko]

Bonjour à toutes et à tous
j'ai un souci avec les jars "modulaires" en Java 9
Je fais des tests avec la recherche de ressources avec getResource(nom)
et je n'ai pas des résultats cohérents
détails:
j'ai une ressource dans un module "com.truc.config" et un module "com.truc" qui cherche cette ressource.
le module-info qui abrite la ressource est lapidaire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
module com.truc.config{}

maintenant tous les modules sont abrités par des jars.
le jar "maitre" a dans son MANIFEST un champ "Class-Path: com.truc.jar com.truc.config.jar"
Si je lance le jar maitre la ressource est trouvée! (elle a un nom relatif par rapport au package de la classe demanderesse)
Or:
- ça ne devrait pas se produire d'après les specs (le module n'est connu que depuis le MANIFEST pas dans les directives des module-info)
- ça ne marche pas si on lançe une commande sans jar: "java -p module-path module/leMain"

donc questions:
- comment se fait-ce que le jar n'aie pas le même comportement?
- quel est la règle officielle garantie sur facture pour lire une ressource abritée dans un autre module? (opens dans le module-info n'a pas l'air de marcher non plus)

Merci pour toute suggestion ...

[bouye]

Le soucis je pense c'est le JDK9 et les modules même si tu n'en utilises pas. Il n'est plus possible désormais d'utiliser des packages éclatés sur plusieurs JARs. Et cela impact aussi l'acces aux ressources contenues dans l'autres JARs si tu passes par certains types de ClassLoader. Bef, avant de chercher a corriger ton projet principal, je te conseille de faire un projet de test très très simple avec 2 JAR et de voir si une des variantes de getClass().getResource(), getClass().getResourceAsStream(), getClassLoader().getResource(), etc. etc. etc. fonctionne encore ou si plus rien ne passe.

Bon apres il faut temperer ce que je viens d'expliquer par le fait que mes propres tests se sont heurtes a des soucis avec le compilateur ou le faible support des IDEs donc, ma reponse n'est pas 100% fiable.

[professeur shadoko]

ce que je comprends à ce stade:
- il y a deux types de PATH: le class-path classique et le module-path. dans le class-path on trouve les jar "non modulaires" et dans le module-path ceux qui le sont. Comme les modules décrivent un graphe à partir du module initial on doit pouvoir trouver les modules dont il dépend dans le module-path
- est-ce que le champ Class-Path ne concerne que les jars non modulaire ? probablement. Maintenant si on clique sur le jar "maître" où trouve-t'il son module-path?
- pour les ressources j'ai toujours pris grand soin de les déployer dans un "package" différent ... donc pas de problème de ce coté là. Mais si on ajoute au déploiement des jars de ressources faut-il:
** ne pas les mettre dans un jar modulaire et le répertorier dans le class-path (dans jar ou option de lancement de java)
** lancer java avec l'option patch-module pour rattacher notre jar de ressource au module demandeur
** avoir un jar modulaire de ressource ... mais alors comment décrire son module-info et qui fait requires?

pour sûr une grande partie de mon incompréhension vient du fait que les IDE gèrent ça n'importe comment et qu'on ne voit pas a priori de politique claire.

Merci pour toute suggestion

[adiGuba]

Salut,


Attention j'ai pas vraiment eu le temps de tester les modules de Java 9, donc je peux me tromper.
Toutefois j'avais pas mal lu les docs et j'ai peut-être des pistes...

- comment se fait-ce que le jar n'aie pas le même comportement?

Je pense que c'est juste un mode de compatibilité.

Lorsque tu utilises java -jar xxx.jar, Java 9 doit probablement utiliser les anciennes règles de chargement des classes.
Donc la notion de module est "désactivé" pour rester compatible... d'où le comportement différent.

- quel est la règle officielle garantie sur facture pour lire une ressource abritée dans un autre module? (opens dans le module-info n'a pas l'air de marcher non plus)

Comment tu définis ton module avec opens, et qu'est-ce que tu utilises pour charger les ressources : Class, Module ou ClassLoader ?



a++

[professeur shadoko]

Merci pour les réponses:

Lorsque tu utilises java -jar xxx.jar, Java 9 doit probablement utiliser les anciennes règles de chargement des classes.
Donc la notion de module est "désactivé" pour rester compatible... d'où le comportement différent.

pas de doc sur ce point! plus inquiétant: comment alors faire un déploiement simple (jar "cliquable")?
les scripts et les images jlink ne sont pas ce qu'il y a de plus portable ... je n'ose même pas imaginer quelles contorsions il va falloir faire pour java webstart. (edit: oups c'est fait! webstart deprecated!)

Comment tu définis ton module avec opens, et qu'est-ce que tu utilises pour charger les ressources : Class, Module ou ClassLoader ?

au départ avec Class, on m'assure que ça marche avec ClassLoader mais j'ai pas réussi.
(open module truc {} -> marche pas, opens package encore moins -> la compil du module-info est refusée par IntelliJ!)
Il semblerait que le chargement traditionnel des ressources est "has been" et qu'il faut envisager de passer par un service et un spi du type de ce qui se fait pour les ResourceBundle.
avantage: pas à torturer encore plus le système de modularité
inconvénient: pourquoi faire simple quand on peut faire compliqué?

A+

[bouye]

A final important difference is that non-class-file resources in a module are encapsulated by default, and hence cannot be located from outside the module unless their effective package is open. To load resources from your own module it’s best to use the resource-lookup methods in Class or Module, which can locate any resource in your module, rather than those in ClassLoader, which can only locate non-class-file resources in the open packages of a module.

Et voir aussi la réponse juste audessous avec une vidéo.

[professeur shadoko]

Et voir aussi la réponse juste audessous avec une vidéo.

Oups j'ai regardé (c'est long!)... j'ai pas trouvé de réponse précise
(ou alors j'ai fait une faute d'inattention à un moment).
La nouveau comportement de getResource du ClassLoader reste un mystère pour moi.
d'ailleurs je n'arrive pas à le faire fonctionner: les désignations de paramètre que je donne marchent pour Module mais pas pour ClassLoader ... il doit y avoir un truc que je n'ai pas compris

ex: dans le module courant pour Module getResourceAsStream la chaine "com/maboite/withprops/konfig/vals.properties" marche ... mais tintin pour ClassLoader getResource ... j'ai essayé différents formats (avec slash au début, avec nom du module au début, etc... "opens" ne change rien à l'affaire ... d'ailleurs IntelliJ refuse de faire "opens" sur un pseudo-package qui ne contient que des ressources mais bof!) ... rien!

[bouye]

Non je me suis mal exprimé, la vidéo appuie la réponse sur StackOverflow qui dit que le classloader n'a pas changé par rapport aux version précédentes.

[professeur shadoko]

j'ai posté sur stackoverflow une suggestion de code pour gérer les ressources avec un service.
Le code est loin d'être parfait: toute suggestion d'amélioration est la bienvenue.
en voici une copie:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
public interface ResourceLoader {
    public static Optional<URL> resourceSearch(Class clazz, String name) {
        String fullPath = name ;
        if(! name.startsWith("/")) {
            String packageName = clazz.getPackageName();
            fullPath = '/'+packageName.replace('.','/')+ '/' + name;
        }
 
        ServiceLoader<ResourceLoader> loader = ServiceLoader.load(ResourceLoader.class);
        for(ResourceLoader resourceLoader: loader) {
            Optional<URL>  anUrl =resourceLoader.getResource(fullPath);
            if(anUrl.isPresent()) {
                return anUrl ;
            }
        }
        return Optional.empty() ;
    }
 
    public static Optional<InputStream>  resourceSearchAsStream(Class clazz, String name) throws IOException {
        Optional<URL> anURL = resourceSearch(clazz, name) ;
        if(anURL.isPresent()){
            InputStream is = anURL.get().openStream() ;
            return Optional.of(is) ;
        }
         return Optional.empty() ;
    }
 
    public default Optional<URL> getResource(String fullPath) {
        Class localClass = this.getClass() ;
        URL res = localClass.getResource(fullPath) ;
        return Optional.ofNullable(res) ;
    }
}

le module info du module qui contient les ressources

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
open module com.maboite.withprops.config {
    requires com.maboite.withprops;
    provides com.maboite.withprops.utils.ResourceLoader with com.maboite.withprops.spi.ResourceLoaderImpl ;
}

le code de "ResourceLoaderImpl" est trivial !
à part ça pour le problème des jars "clickables" je cherche ...

[professeur shadoko]

La nouveau comportement de getResource du ClassLoader reste un mystère pour moi.
d'ailleurs je n'arrive pas à le faire fonctionner: les désignations de paramètre que je donne marchent pour Module mais pas pour ClassLoader ... il doit y avoir un truc que je n'ai pas compris

il y avait surtout un bug dans mes codes ... getResource marche (presque) comme avant ... à la condition que le module fournisseur fasse un "open" sur la ressource.. (c'est bien sûr écrit -pas très clairement- dans la doc ... mais comme j'étais dans un enfer de bug je n'arrivais pas à le croire )

[bouye]

Histoire de rajouter de l'eau au moulin, Mark Reinhold, l'ingenieur en chef du JDK vient de poster

- As of Java 9, with Jigsaw, there are two ways in which a library can
be used: Either on the traditional class path, or on the newfangled
module path. If you maintain a library but don't modularize it then
it can still -- unbeknownst to you -- be used on the module path as
an automatic module.

- When code runs on the module path there are some differences in the
behavior of some pre-9 APIs, in particular those related to resource
lookup.

- As a consequence, if you maintain a library that's intended to work
on Java 9 or later then you should test it on both the class path
and the module path, even if you do nothing to convert your library
to a module. If your library doesn't work on the module path then
you should either fix it or document that limitation.

- If you don't modularize your library, or at least claim an automatic
module name for it via the `Automatic-Module-Name` manifest entry,
then you potentially block the maintainers of libraries that depend
upon yours from modularizing their own libraries.

- The tools that we use, and in particular Maven, could be improved.
It's difficult to compile the classes for a modular JAR file that's
intended to work on the class path of pre-9 releases, it's difficult
to test a library on both the class path and the module path, and
various Maven plugins still need to be upgraded to handle (or else
ignore) `module-info.java` files. (Stephen has helpfully filed
issues in the appropriate bug trackers for some of these problems.)

- Some old tools, bytecode libraries, and other systems fail when they
encounter `module-info.class` files or multi-release JAR files