Reprise du message précédent :
Bonjour,
 
J'ai trouvé ce sujet et j'espère que mon problème est bien un problème de classpath...
 
J'ai créé un jar exécutable exporté depuis Eclipse. L'application lit des fichiers binaires au démarrage.
J'ai placé ces fichiers dans le répertoire : /home/nom/workspace/dataset/
J'ai fait un export de la variable CLASSPATH sous Linux : CLASSPATH=/home/nom/workspace/dataset/
 
Quand j'exécute : java -jar MonJar.jar j'ai l'erreur  
 
java.io.FileNotFoundException: POINTS.AIF (No such file or directory)
 
POINTS.AIF est l'un des fichiers à lire...
 
Si je me contente de mettre le jar dans le même répertoire où se trouve les fichiers binaires à lire, ça marche.
 
Où est le problème ? Merci.

c'est juste que tu ne précises pas où lire tes fichiers.
 
tu dois, je suppose, les loader avec new File('POINTS.AIF'), et donc ça n'est pas lié au classpath
 
il faut que tu précises le répertoire où sont tes fichiers : new File('/home/nom/workspace/dataset/POINTS.AIF')
 
et donc éventuelleme passer le répertoire où se trouvent tes fichiers en paramètre

 
Oui, c'est ça. Je fais un new FileInputStream("POINTS.AIF" ).
 
Mais un collègue m'avait indiqué qu'il avait pu indiquer un répertoire de travail dans lequel la JRE cherchait les fichiers si elle ne les trouvait pas ailleurs. N'est-il pas possible d'indiquer un Working Directory à la JRE ???
 
Merci !

bhé tu fais cd /home/nom/workspace/dataset avant de lancer ton jar. Ca sera ton répertoire de travail

 
OK merci. Ca marche ainsi. Du coup, je suis passé par l'option "-D" pour récupérer le chemin car je ne voulais pas avoir à être dans ce répertoire au lancement.
 

si je spécifie une liste de jar dans le manifest il y a pas moyen de rendre paramétrable le chemin de base où ces jar seront cherchés ?

edit : en fait le chemin que le jvm prend comme base, c'est le chemin courant du shell
c'est vraiment pas souple

edit2 : non, c'est relatif par rapport à l'emplacement du jar passé en paramètre de -jar

Bonjour, svp je voudrai vous demander comment rajouter tout les .jar a classpath quand on en a plusieurs. merci

Bonjour, svp je voudrai vous demander comment rajouter tout les .jar a classpath quand on en a plusieurs et que c'est impossible de donner tous les path un par un. merci

s'il sont tous dans le même répertoire avec un script dos tu peux faire un truc du genre  
for /f %%f IN ('dir /b %LIB_REP%\*.*') DO set CLASSPATH=!CLASSPATH!;%LIB_REP%\%%f
 
Dans mon exemple %LIB_REP% est une variable correspondant au chemin du répertoire contenant les jar

 
je vous remercie pour la réponse, auriez vous l'amabilité de m'expliquer ce script Svp.  

Question classpath (je suppose)
 
J'ai une lib (Java Communications API 2.0.3 pour na pas la citer, communication avec ports série et parallèles) qui a des dépendances binaires.
 
Elle nécessite une installation avant exécution, avec la copie d'une DLL (on est en environnement Win 32, pour les besoins de cette question on en restera là), d'un Jar et d'un .properties dans les répertoires JRE_HOME/bin et JRE_HOME/lib. Problème : ça nécessite d'avoir les droits d'administrateurs durant l'install (écriture sur le c: dans un répertoire d'application, © lolcorp).
 
Je voudrais m'abstraire de ça, je me dis - c'est peut-être faux - que ce n'est qu'une simple présence des fichiers en question dans le classpath de l'appli.
 
Problème : autant une dépendance transitive sur un Jar pour la bazillions de projets qui utilisent cette lib, OK, autant inclure automatiquement les fichiers en question (DLL et .properties) dans tous les projets qui ont une dépendance vers cette API, je vois déjà nettement moins.
 
Des idées ?

je crois qu'il "suffit" que la dll soit dans le path (pas le classpath)

si c'est du jni

donc au lancement un .bat avec un truc genre

SET path=%path%;cheminDeTonDLL

devrait aider

il y a aussi une variable java.library.path qui est trouvable dans Système.properties(   ) qui contient le classpath système mais la modifier dans l'application java n'a du coup pas d'effet car c'est trop tard

 
Effectivement, je vais tester mais ça parait logique.
 
Pour une appli type Jar exécutable, ça doit pouvoir le faire, pour une lib inclue dans un environnement JEE type serveur d'application, j'y crois déjà moins, à voir. Par contre, reste à "penser" à chaque utilisation de l'API a faire ces modifs dans le PATH à la mano. J'aurais réellement aimé avoir un artéfact propre qui intègre tout le nécessaire.
 

mate comme jdesktop fait, par example. jpense y'a moyen de foutre le dll *dans* ton jar, par exemple

 
en jee c'est pareil, il faut traffiquer les fichiers env .bat
le jar qui nécéssitait le dll fonctionne sur un lib utilisée dans des ear sur serveur d'appli ou dans des batchs java -jar

 
Ca serait l'idéal effectivement.
Sauf que je ne connait pas JDesktop, et que le seul truc approchant que je trouve sur l'intarweb est ça : http://java.net/projects/jdnc/sour [...] nk?rev=474
 
Je mate le build.xml et les make, mais je vois rien d'approchant, c'est bien ce projet ?

Je vois pas mal de pistes qui conseillent de wrapper la DLL dans le Jar, puis à l'initialisation de l'extraire et de la charger (System.load()). Je ne sais pas encore si ça équivaudra à l'inclusion dans le PATH.
 
Il est conseillé dans ce cas d'extraire vers le java.library.path, qui demande les droits d'admin pour écriture
Je vais tester avec un répertoire courant et voir ce que ça donne.

et si tu surcharges le java.library.path ?

J'ai fait quelques tests de plus. Fun fact : la librairie qui utilise le binaire ne renvoi pas d'erreur si quelque chose se passe mal, ce qui facilite grandement le debug, vous devez vous en douter.

Soit la lib incriminée (Java Communications), composée de :
- comm.jar, en théorie à mettre dans JRE_HOME/lib ;
- javax.comm.properties, en théorie à mettre dans JRE_HOME/lib ;
- win32com.dll, en théorie à mettre dans JRE_HOME/bin.

le tout nécessite donc les droits d'admin.

J'ai autour de ça une lib wrapper qui s'occupe d'installer le tout (quand utilisateur admin) et ajoute une couche d'abstraction.

1er test

Une classe (appelons-la com.foo.Test dans com/foo/test.java) fait les appels nécessaires. La DLL est dans bin/, les libs et .properties dans lib/

La classe est exécutée par le bat suivant :

SET PATH=%PATH%;.\bin
SET CLASSPATH=.
SET CLASSPATH=%CLASSPATH%;.\lib\comm.jar
SET CLASSPATH=%CLASSPATH%;.\lib\wrapper.jar
SET CLASSPATH=%CLASSPATH%;.\classes
 
java -classpath %CLASSPATH% com.foo.Test

Et là Twingo, ça fonctionne \o/ On note pourtant qu'à aucun moment, je ne me préoccupe du fichier .properties, lui aussi dans lib/

2ème test

La même classe est montée en projet Maven, avec les dépendances vers comm.jar et wrapper.jar, le .properties et la DLL en resource, le tout génère un Jar with dependencies (le .properties et la DLL sont à la racine du Jar).

Avant toute chose, le programme copie la DLL dans un répertoire temporaire contigüe au jar (.\bin), puis charge le fichier à l'aide de System.load().

Et là, c'est le drame, ça ne fonctionne plus (bien évidemment sans message d'erreur) /o\

Edit : le "pas de message d'erreur" semble pointer un défaut de chargement du .properties, pourtant à la racine du Jar généré. Je continue...

Je garde la piste, il faudrait pour ça que j'identifie si l'échec mentionné plus haut est dû au System.load().

y'avait pas un fork/remplacement moins chiant que comm.jar qui était sorti y'a qques années ?

Je suis pas au courant, mais si ça existe je suis plus que preneur !

Edit : RXTX demande une copie dans les mêmes répertoires que javax.comm, serialio est payant, jSSC demande que le projet final embarque l'une des DLL.

ha bah ché plus alors rxtx me dit qqch, donc ça doit etre ça qu'on a fini par utiliser, mais jte parle de y'a quasi 10 ans là

SET PATH=%PATH%;.\bin
SET CLASSPATH=.
SET CLASSPATH=%CLASSPATH%;.\lib\comm.jar
SET CLASSPATH=%CLASSPATH%;.\lib\wrapper.jar
SET CLASSPATH=%CLASSPATH%;.\classes
 
java -classpath %CLASSPATH% com.foo.Test

Moar tests

Si durant le test 1, je n'inclue pas le binaire dans le PATH, le message d'erreur suivant est généré :

On est dans le contexte où les Jars sont dans le classpath, le .properties est dans le même répertoire mais pas explicitement chargé. Si on ajoute la DLL dans le PATH, ça roule, sinon message d'erreur plus haut.

On repasse au test 2. Pour rappel, j'ai toutes les dépendances qui sont dans le même Jar exécutable (Jar with dependencies), et je tente les manips suivantes dans le code :
- copie de la DLL en dehors du Jar, puis chargement avec System.load() ;
- setting de System.properties avec les valeurs contenues dans le .properties.

Et bien là, ça fonctionne pas, mais sans message d'erreur. Plus fort, quand je supprime le load de la DLL (donc potentiellement même cas de figure que mon ce que j'expose plus haut avec le test 1), ça fonctionne toujours pas, mais sans aucun message d'erreur (même pas le "Error loading win32com..." ). J'avoue que je ne comprend pas.

Tout se passe comme si la lib comm.jar était "appelée" avant ladite exécution du programme quand elle est explicitement incluse au classpath (test 1), et que ce n'était pas le cas quand son contenu est dans le Jar applicatif.

Dites moi que vous avez une idée  

idéalement tu dois avoir quelques .properties en dehors des jars, pour pouvoir changer sans recompiler
donc de toutes façons il faudra les indiquer de façon relative ou absolue et passer leur emplacement en parametre avec -DfichierConf=%FICHIER_CONF%
 
à partir de là t'es plus à ça près, donc devoir ajouter ton au path avec SET PATH=%PATH%;.\bin  c'est pas dramatique
 
Et surtout, embarquer un binaire dépendant de la plateforme dans un jar, à la limite si c'est impossible, heureusement

 
Non justement.
Y'a qu'une property, c'est le nom du driver chargé, la DLL. La lib est Win 32 uniquement, donc elle peut très bien embarquer le code natif tant que ça simplifie mes builds.

L'interface JNI, Java Native Interface à justement pour but de découpler le code binaire du byte code.
 
Si ton dll doit être en dehors du jar et sur le system de fichier c'est normal, c'est prévu pour que ça fonctionne comme ça.
 
Et je pense qu'a moins de décompiler la jvm et de la bricoler tu ne pourras pas faire autrement.
Ca serait pas étonnant que chez Sun ils aient fait tout leur possible pour que ce que tu tentes de faire ne soit pas possible.    
 
tu n'as pas dis précisément le façon dont tu compte utiliser le jar

 
Je pense que tu as raté ce passage :
 

 
Et je cherche pas à contourner des restrictions sur JNI mais bien des emplacements d'installation par défaut qui m'arrangent pas. Le test 1 montre qu'en pratique ça ne pose strictement aucun problème.
 

 
Non, parce que ça n'a aucune rapport avec la choucroute. Ma question est "voyez-vous un moyen de contourner les emplacements d'installation préconisés, idéalement en incluant les dépendances dans un artéfact", pas "est-ce que cette façon de procéder vous semble apropriée / jolie / whatever" . J'ai détaillé le pourquoi de ce besoin (droits d'administrateurs notamment) et j'ai dit que la lib serait utilisée dans d'autres programmes (du client lourd à l'appli JEE), c'est suffisant comme contexte.
 

tu veux pourtant un truc qui soit joli à l'usage

pour un serveur d'appli il y a pas de solution qui ne nécéssite pas de soit installer le dll direct dans le path, ou le mettre ailleurs en étendant le path dans le .bat de lancement du serveur d'appli

si tu fournis une application packagée dans un zip ou un autoinstalleur qui sera lancé par jvm avec un jar -jar alors tu as la solution de ton premier Test avec bundlage de la dll, dans ton zip, et modif du path dans le .bat

si tu veux que le jar de ta lib soit mis à dispo sur un dépos maven, tu as pas d'autre choix que de laisser à ceux qui vont utiliser ta lib de choisir entre les deux solutions précédentes

j'ai rencontré ce problème pas plutard qu'il y a deux semaines

l'idéal serait de pouvoir pondre un message d'erreur clair pointant vers une page de doc, mais l'exception qu'on se prend c'est plutot un message obscure genre la dll machin est pas trouvé

j'ai eu des soucis similaires avec des librairies de cryptage
aux us ils authorisent une taille de clef max de 1024 ou qqchose comme ça
donc la jvm est fournie avec ces lib là, et sun fournit les autres libs à part
et on a juste un message disant illégal key size, et il faut se taper l'install à la main en déposant les bon jar dans le dossier de la jvm

Je réessaie une dernière fois, toujours le même passage que tu n'intègre pas.
 
1. Je veux éviter de poser la DLL dans le répertoire préconisé, pour des problématique de droits
2. Mon test 1 montre que, quelque soit l'emplacement de la DLL sur le disque, si je l'intègre au PATH, win
3. Cette solution est fonctionnellement valide, mais elle demande de conserver une "hygiène" de déploiement assez stricte pour pas mal d'applications finales qui intègreraient cette lib dans leur dépendances, avec potentiellement plusieurs niveaux de transitivité
4. D'où, et partant du postulat 2), mon wrapper embarque la DLL dans son Jar, l'extrait dans un répertoire temporaire (donc sur le disque) et charge la DLL. Je fais ça avec System.load(), et là fail.
 
Problème (et donc ma question) : en intégrant la DLL au PATH (mais c'est une configuration externe à l'API), ça marche, en la chargeant avec System.load(), ça foire, et c'est dommage parce que je ne connait pas d'autre moyen dans le code, et c'est là dessus que je demande vos avis.
 
Toute autre considération ne m'intéresse pas dans mon cas précis.

comm.jar il a besoin de la librairie .dll on est d'accords ?
Comment il fait pour charger la librairie ?

C'est exactement ma question.

Test 1, la DLL est dans le PATH, comm.jar est dans le classpath de l'application (java -cp %CLASSPATH% MaClasse) => ça fonctionne
Test 2, comm.jar est dans le Jar exécutable de l'application (java -jar monJar.jar), ça fonctionne pas, que ce soit avec la DLL appeler via System.load() ou par la DLL dans le PATH.

C'est ce cas de figure que je ne comprend pas et auquel je cherche un palliatif.

A minima, je saisi pas la différence de comportement entre l'exécution avec la dépendance dans le classpath et le Jar exécutable.

Si tu as une explication (autre que "je ne comprend pas ce que je veux faire" ou "ça ne marche pas comme ça" ), je prend, sinon je vais rester sur mon premier cas.

Edit : edit de fourbe

le test 1 ok, ça marche donc rien à comprendre
le test 2 alors personnellement je me rappelle pas que mettre un jar dans un autre jar ça soit possible. Pour un war ou un ear ok, mais pour un jar je crois pas avoir vu ça.
 
Sinon si je te demande comment comm.jar charge la librairie dll, c'est parceque lui même doit probablement aussi faire un Sytem.load().
 
Et comme le load est fait en statique probablement pour qu'il soit chargé dès le lancement du jar par la JVM , avec un
public class Comm {
static {Sytem.load( ... ) }
}
 
Alors tu pourras difficilement te substituer à la façon qu'il a de chopper le dll si l'api n'a pas prévu que ce ça soit faisable par un paramètres quelconque.
 
a mon avis c'est ce qui se passe    
 
mais là je te sens parti pour décompiler la classe
 
enfin pour moi a première vu il y a pas de solution qui n'impliquerait pas du gros hack ou et de recoder comm.jar  

je me suis mal exprimé. C'est un Jar with dependencies, les dépendances sont désarchivées et inclues dans le Jar (les classes des dépendances copiées dans le Jar exécutable).

Étant donné que ça fonctionne quelque soit la localisation du Jar, je pense plutôt à un System.loadLibrary(), qui lui prend un nom de librarie dispo dans le path.

Sauf que ça n'explique pas pourquoi le premier test marche et pas le second, puisque la lib est dans les cas dispo dans le path. Also, si c'est ce que se contente de faire la lib, ça n'explique pas pourquoi ça ne marche pas quand je charge explicitement la DLL avant tout appel à comm.

Edit : j'ajoute que System.loadLibrary() fonctionne. Si la lib indiquée n'étant pas présente dans le PATH, j'aurais droit à une exception. Si je résume, la DLL est chargée dans les deux cas, donc y'a bien autre chose qui fait foirer le truc.

j'ai découvert récement que le code
 
static {
 
}
 
static final String bidule= new String("bidule);
 
est exécuté que si une méthode de ton code au runtime fait référence à cette classe, que ce soit en static ou autre
 
a toi de voir à quel moment l'api fait son appel à System.loadLibrary( ) car il le fait peut être avant toi
 
bonne décompilation
 
je pense que tu as une meilleure visibilité sur ton problème que nous
la c'est super technique, à toi de voir si ça vaut le temps dépensé
 
c'est une appli de payement c'est ça ?
 
ha non si c'est sur serveur

OK, bonne piste merci ! Je testerais ça la semaine prochaine maintenant.
 
Le wrapper développé chez nous est une sorte de gros drivers vers un équipement qui se pilote par des commandes AT (comme du GSM). C'est encore très utilisé dans l'industrie, et on a un bon paquet d'applis maisons qui dialoguent par ce biais.  
 
Alors ça marche tel quel certes, mais mon acharnement c'est plus de la curiosité et l'envide de comprendre le pourquoi de la chose

Pour éviter de continuer la pollution du topic classpath, la suite ici : http://forum.hardware.fr/hfr/Progr [...] 6363_1.htm

Bonsoir,
 
Je suis débutant en Java, et j'ai un problème lors de l'exécution.
 
Lorsque je compile puis exécute des programmes qui sont sur un seul fichier, tout se passe bien : je ne suis pas sur que ça soit un problème de path.
 
Mon prof nous a donné un programme en trois fichiers qu'il faut exécuter et comprendre. Mais je n'arrive pas à compiler.
Il y a trois fichiers, tous dans le répertoire courant : Auteur.java Livre.java et TestLivre.java
 
Le main est dans TestLivre.java
Je compile en faisant ceci :

J'exécute en faisant ceci :

 
J'obtiens ce message d'erreur :

 
Je mets mon fichier TestLivre.java au cas où :

 
Quelqu'un saurait-il m'aider s'il vous plait ?
J'ai aussi essayé de compiler et d'exécuter avec l'option -classpath, sans succès  

package bibliotheque ;  --> java bibliotheque.Truc
Tu diras à ton prof que Livre et Bibliotheque ne sont pas des mots anglais, merci.

D'accord, merci pour ton aide.
Mais quand je tape java bibliotheque.TestLivre j'obtiens un message similaire :  

.