Bonjour à tous
 
Je cherche à savoir pourquoi l'exécution d'un programme est différente selon le mode d'exécution (class ou Jar).
 
Le code en question ajoute un répertoire au path courant en vue du chargement d'une librairie (DLL Win 32) par une API tierce (Sun Comm). On trouve l'arborescence suivante :
 

 
et le code
 

package com.foo;
 
public class ComTester {
 
    static {
        System.out.println("Modifying PATH..." );
        try {
            addDir("\\absolute\\path\\to\\test-app\\bin" );
        } catch (IOException e) {
            System.err.println(e.getMessage());
        }
        System.out.println("Setting properties..." );
        System.setProperty("Driver", "com.sun.comm.Win32Driver" );
    }
 
    public static void main(String[] args) {
        final Enumeration<CommPortIdentifier> comPorts = CommPortIdentifier.getPortIdentifiers();
        while (comPorts.hasMoreElements()) {
            System.out.println("Port: " + comPorts.nextElement().getName());
        }
    }
 
    private static void addDir(String s) throws IOException {
        // java.library.path ne peut être settée durant l'exécution, cette méthode permet de passer outre la limitation
        // Voir http://stackoverflow.com/q/5419039
    }
 
}

 
Lorsque j'exécute ce code via  
 

SET CLASSPATH=.
SET CLASSPATH=%CLASSPATH%;.\lib\comm.jar
SET CLASSPATH=%CLASSPATH%;.\classes
 
java -classpath %CLASSPATH% com.foo.ComTester

 
youpi c'est la fête, les ports série et parallèle dispos sur la machine sont affichés.
 
Par contre, via :
 

java -jar .\target\test-app.jar

 
avec le class-path correctement setté dans le Manifest, ça ne fonctionne plus, sans message d'erreur (les autres printf sont affichés normalement, tout se passe comme si il n'y avait pas de ports dispos sur la machine, signe pour cette API qu'il y a un souci au chargement).
 
Pour les deux types d'exécution :
- le class-path est correct, puisque quand il ne l'est pas, le code lance une ClassNotFoundException.
- l'API tierce (comm.jar) se charge bien du System.loadLibrary() sur la DLL, puisque quand cette dernière n'est pas ajoutée au PATH, le premier appel à l'API lance une UnsatisfiedLinkError.
 
Piste sans doute intéressante : lorsque le Jar de l'API tierce est renommé (comm.jar vers comm-foo.jar par exemple), aussi bien l'exécution class que Jar ne renvoient pas de résultat (les printf, pas de message d'erreur mais pas de port affiché). C'est le comportement du Jar lorsque le class-path est correctement renseigné.
 
Le comportement du classloader est pourtant identique du point de vue de l'API tierce que l'on exécute par class ou par Jar (vérifié par en diff entre les exécutions en -verbose).
 
Des idées    
 

J'aurais aimé upper avec des infos plus constructives, mais vraiment je sèche.
 
Je rappelle que le problème peut se résumer à "pourquoi deux moyens d'exécution différents (class et jar) d'une même application renvoient deux résultats différents ?"
 
 

Je vais tenter une explication différente.
 
Soit le bout de code précédent qui fait un appel tout bête à une API (comm.jar).
 
Pour que cela fonctionne (selon la doc), il faut que le fichier javax.com.properties soit situé dans JAVA_HOME/lib. On peut donc penser que l'API comm fait quelque part un properties.load sur le path absolu en se servant du JAVA_HOME.
 
Sauf que ce n'est pas le cas, puisqu'en exécutant mon programme avec  
 

 
Ça fonctionne si le .properties est dans le répertoire courant (on va appeler ça le Cas 1, qui fonctionne). Pourtant, nulle part je ne set le classpath avec le répertoire courant. Ce que prouve à mon sens le Cas 1, c'est que le .properties n'est aps chargé avec un chemin absolu, preuve qu'il est potentiellement possible de le charger de n'importe quelle manière.
 
Encore plus fort, si je met le .properties dans un autre répertoire et que je l'inclus au classpath de la commande précédente, ça ne fonctionne pas (Cas n° 2). Ça ça m'intrigue, je n'ai pas d'explication.
 
Si je reprend le cas n°1 (celui qui fonctionne) en modifiant le nom du Jar de l'API, ça ne fonctionne plus :
 

 
pas d'explication non plus là dessus, appelons le cas n°3.
 
Enfin, si je reprend le cas n°1 (qui fonctionne, .properties à la racine) avec un Jar exécutable (et le répertoire courant ajouté au classpath dans le manifest de celui-ci), ça ne fonctionne pas non plus. C'est le cas n°4, et potentiellement mon objectif à terme.
 
 

par curiosité, j'ai googlé ce matin et j'avais pas mal de références pointant des limitations de classloading et apparemment, il y a qques custom class loader utils qui ont été créés pour être plus puissants que le classloader par défaut.
 
tu es p-ê à la limite de leur modèle générique ?

Si je te suis, la (une) limitation du classloader amènerais un chargement différent des dépendances en fonction du mode d'exécution (Jar ou class) ?
 
Ça me marrait plus un bug qu'une limitation sans plus de détail sur le fonctionnement.
 
De plus, j'ai vraiment pas l'impression de monter un cas complexe, c'est aussi pour ça que je suis si étonné de ne pas trouver d'explications sur mon problème.

c'est l'impression que j'avais en lisant 2~3 posts trouvés ce matin (java limitation classloader native dll)

Autant les liens sont intéressants, autant j'ai l'impression que mon problème se situe en amont (ce que je tente d'expliquer dans mon 3ème post).
 
Avant même le chargement de la lib (qui lui ne me pose pas de problème), c'est le chargement des properties en fonction du contexte d'exécution qui me laisse perplexe. Ça et le cas n°3 (dépendance renommée) qui me laisse pantois.

Non mais euh au lieu de faire dans l'empirique, t'as maté les sources de comm.jar pour voir comment le bordel est initialisé?

je pense à un cas où bosser à partir du jar dézippé ou du jar zippé peut poser problème
c'est si le jar est signé
le manifest contient alors la signature de chaque classe contenue dans le jar
 
je connais pas le mécanisme, ni la manifestation des conséquences mais c'est le seul cas qui me vient à l'esprit

je viens de downloader je jar, c'est bien ça, il est signé
 
donc dans le cul lulu
 

 
sinon je vois pas pourquoi tu veux absolument dézipper le comm.jar, ça n'a pas d'intérêt, et ça t'a même fait perdre ton temps

 
Si elles étaient dispos, j'aurais effectivement commencé par là
 
J'ajoute :
 

 
( http://java.sun.com/products/javac [...] index.html )
 

 
Le code que dont je fais varier l'exécution (soit en Jar soit en classe) est de mon côté, et pas signé quand il est sous forme de Jar.
comm.jar est effectivement un Jar signé, mais est lui toujours appelé sous cette forme (i.e. quand mon code est sous forme de classes/*.class, comm.jar est intégré au classpath => ça fonctionne).

 
Bin je veux pas    
 
Tu peux restreindre ce qui marche pas / ce que je veux faire à mon 3ème post, à aucun moment il est question d'exploder les dépendances.

mais ça répond à ton cas 3 je pense
 

SET CLASSPATH=.
SET CLASSPATH=%CLASSPATH%;.\lib\comm.jar
SET CLASSPATH=%CLASSPATH%;.\classes
 
java -classpath %CLASSPATH% com.foo.ComTester

java -jar .\target\test-app.jar

 
ça je crois que c'est "normal" que ça marche pas
 

java -jar .\test-app.jar

 
ça ça doit marcher
 

 
 
je me suis arraché les cheveux sur ce genre de trucs déjà, et il y a des comportements bizarre au niveau des chemins relatifs de class path
 
j'ai de plus jamais vraiment réussit à utiliser -classpath %CLASSPATH_LIB% -jar %JAR% conjointement
nottament à cause du fait qu'il faut spécifier le nom de chaque jar dans %CLASSPATH_LIB% ce qui est bien lourd
du coup à ce moment là autant faire en sorte que maven génère automatiquement le classpath dans le manifest
 
mais du coup on ne peut plus gérer dynamiquement l'emplacement des librairies dépendentes
bref, c'est la merde pour avoir un truc clef en main et facile à maintenir
 
 
je pense que tu donnes pas assez de détails
il faudrait ton pom, le contenu de ton manifest généré etcetera

 
C'est pas un problème de classpath (au sens entrée dans le manifest), celui-ci est bon et a été vérifié (et re vérifié) dans tous les tests que je mentionne.
Si il y a une coquille, considère que c'est dans la rédaction de mes posts (ou plus exactement que les tests du troisième post sont indépendants de ceux du premier).
 

 
C'est surtout dû au fait qu'en cas d'exécution par le commutateur -jar, la seule entrée de classpath prise en compte est celle du manifest, donc ce que tu poses après ton -cp est ignoré.
 
Je répète, je vous aurais certainement pas tanné avec un bête soucis de classpath mal setté, les chemins sont corrects lors de mes tests et devraient en toute logique (la mienne en tout cas) fonctionner en l'état.
 
Par contre, ton hypothèse sur le Jar signé qui ne "fonctionne" plus une fois renommé, ça se tient
 
 
 

mais c'est un peu bancal, car je vois pas mention du nom du jar dans le manifest

 
Mais qu'est-ce qui est bancal    
 
Je t'ai dis d'oublier mon premier post et de ne raisonner que sur le 3ème. Dans celui-ci, je ne donne pas de manifest, donc c'est vite réglé.
 

 
Dans cette phrase, je sous-entend évidemment que le minimum syndical (les dépendances dans le classpath, ou bundlées dans le Jar) est fait.
 
 

si jamais je l'ai pas encore dit, le truc que j'avais utilisé a l'epoque pour remplacer comm.jar c'était RXTX. Possiblement pas beaucoup mieux, mais open source.