Discussion :

[Trap D]

Bonjour

Je suis sous OpenSuse 64bits, EDI NetBeans 6.9 (mais je ne pense pas que ce soit lié à l'IDE).
J'utilises choco-2.1.0-basic+visu.jar.
Lorsque je travaille avec l'IDE tout fonctionne bien, mais en ligne de commande il refuse d'accepter le jar voilà la première ligne des messages d'erreur

classes/soma/choco-2.1.0-basic+visu.jar: line 1: PK : commande introuvable
etc etc

Quelle est la raison ?

Merci

[CyberChouan]

En plus des messages d'erreurs, pourrait-on avoir la commande que tu as lancée ? Ainsi que la structure de ton projet (organisation des répertoires de librairies) ?
Cela nous aiderait à déterminer l'origine du problème...

[Trap D]

Merci de t'intéresser à mon problème

La commande

Code :

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

java -cp /usr/lib64/jvm/java-1.6.0-openjdk-1.6.0/jre/lib -classpath classes/;classes/soma/choco-2.1.0-basic+visu.jar  soma/soma

Les messages d'erreur (j'ai enlevé tout le rappel des options de la commande java)

classes/soma/choco-2.1.0-basic+visu.jar: line 1: PK : commande introuvable
classes/soma/choco-2.1.0-basic+visu.jar: line 2: ’m†: : commande introuvable
classes/soma/choco-2.1.0-basic+visu.jar: line 3: ‘m†:ŠœœÆ„¡META-INF/MANIFEST.MFE�œ: Aucun fichier ou dossier de ce type
classes/soma/choco-2.1.0-basic+visu.jar: line 19: 1Ç[v5 : commande introuvable
classes/soma/choco-2.1.0-basic+visu.jar: line 19: Ã : commande introuvable
classes/soma/choco-2.1.0-basic+visu.jar: line 20: Ml†:2choco/kernel/solver/constraints/global/scheduling/PK: Aucun fichier ou dossier de ce type
classes/soma/choco-2.1.0-basic+visu.jar: line 21: Ml†:0choco/kernel/solver/constraints/global/matching/PK: Aucun fichier ou dossier de ce type
classes/soma/choco-2.1.0-basic+visu.jar: line 22: Erreur de syntaxe prÚs du symbole inattendu « choco/kernel/solver/constraints/integer/PK »
classes/soma/choco-2.1.0-basic+visu.jar: line 22: `Ml†choco/kernel/solver/constraints/integer/PK'

L'organisation du projet est l'organisation par défaut pour NetBeans 6.9,
les classes de mon projet se trouvent toutes dans "classes" qui est un répertoire enfant du répertoire d'où je lance la commande et où se trouve aussi choco**.jar

Je ne pourrais pas te répondre si tu me poses d'autres questions, je pars demain en vacances, et je reviens début aout.

Salut et merci

[CyberChouan]

Dans ta ligne de commande, je trouve currieux qu'il y aie à la fois les paramètres -cp et -classpath. Je soupçonne que ton problème de classpath vienne de là (même si j'avoue ne pas avoir essayé). Tu devrais donc tenter de regrouper ces deux paramètres en un seul.

[yotta]

Je penses que l'explication est là. cp n'est autre que la version sous forme de diminutif de classpath. Donc, dans les paramètres, il y a en fait répétition de la déclaration, on peut donc penser que seule la seconde est prise en compte et écrase la précédente. Essayez de n'en utiliser qu'une cp ou classpath et déclarez tous vos chemins en séparant ces derniers du caractère ;

[Trap D]

Comme je le craignais un peu, ça ne marche pas. J'ai toujours les mêmes messages d'erreurs.

Le problème pourrait-il venir du jar qui est utilisable aussi bien avec 32 que 64 bits ? (je ne sais pas sous quelle architecture il a été créé.

Merci en tout cas de votre aide

[yotta]

le format JAR etant un format de compression de fichier, il respecte un standard qui ne se préoccupe pas de la nature de la plateforme 32 ou 64 Bits. Je ne penses pas que cette différence ait un rapport quelconque avec votre problème.
Comme le JAR en question est apparament un fichier récupéré, que vous n'avez pas construit vous-même, on peut tout imaginer le concernant.
Bref, la première chose à faire pour en avoir le coeur nette, serait de le décompresser à la main à l'aide d'un jar -xvf nomFichier.jar.
Le tout sur une plateforme 64 bits. Si tout se passe bien, je dirai que d'un point de vue structure, le jar est bon.
En plus, une fois décompressé, vous pourrez nous éditer le fichier manifest, je penses qu'il contient la clé du problème...

[adiGuba]

Salut,


Sous les systèmes "Unix", le point virgule est un séparateur de commande. Grosso modo dans ton cas cela revient à exécuter les deux lignes suivantes :

Code :

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

1
2
3
java -cp /usr/lib64/jvm/java-1.6.0-openjdk-1.6.0/jre/lib -classpath classes/
 
classes/soma/choco-2.1.0-basic+visu.jar  soma/soma

Il faut utiliser les deux-points comme séparateur de chemin, et non pas le point-virgule qui est utilisé uniquement par Windows...


En clair sous Windows :

Code :

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

java -classpath fichierA.jar;fichierB.jar package.Class

Sous les autres systèmes :

Code :

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

java -classpath fichierA.jar:fichierB.jar package.Class

Au passage on utilise le nom de la classe Java style package.Classe plutôt qu'une struture arborescente package/Classe. C'est moin ambigu (même si ca marche aussi). Et l'on n'a pas besoin de spécifier les librairie de la JVM dans le classpath (je dirais même qu'il ne vaut mieux pas)

a++

[Trap D]

Bonjour et merci pour vos réponses.
Ca marche mieux effectivement avec les : plutôt que les ; dans le classpath.
Mais j'ai une nouvelle erreur, beaucoup plus classique le célèbre "Could not find the main class" :

Exception in thread "main" java.lang.NoClassDefFoundError: soma/soma
Caused by: java.lang.ClassNotFoundException: soma.soma
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:264)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:332)
Could not find the main class: soma/soma. Program will exit.

Ce que je ne comprends pas, (je suis débutant en Java) c'est que je suis reparti de la base en compilant avec javac et tenté d'exécuter avec java avec les mêmes options de classpath :
Pour compiler :

javac -cp /usr/lib64/jvm/java-1.6.0-openjdk-1.6.0/jre/lib:.:./choco-2.1.0-basic+visu.jar soma.java DessinSoma.java GetShape.java

Pour exécuter

java -cp /usr/lib64/jvm/java-1.6.0-openjdk-1.6.0/jre/lib:.:./choco-2.1.0-basic+visu.jar soma.soma

La compile se passe sans aucun warning, et l'exécution plante.

[CyberChouan]

Tout d'abord, tu devrais renommer soma en Soma. Par convention, la première lettre d'un nom de classe est une majuscule en java.

Dans le nouveau chargement de ton classpath, n'as tu pas oublié le répertoire "classes" qui contient tes classes compilées ?

Si celui-ci est bien inclu, les classes sont-elles dans une arborescence physique correspondant à leurs package ? (dans ton cas, un seul niveau de répertoire nommé "soma")

La classe soma est-elle bien déclarée dans le package soma ?

[Trap D]

Maintenant, tout fonctionne, et je ne sais pas vraiment pourquoi
Dernier problème mais là c'est un problème machine, mon prog explose la mémoire centrale ! et je crois que je n'y peux rien sauf à prendre une machine avec une véritable architecture 64 bits !

[hwoarang]

Pour info, tu peux augmenter la memoire max utilisée en passant le parametre "-xmxXXX" à l'execution avec XXX memoire max

a+

[Trap D]

Oui merci, j'ai essayé en mettant -xmx3528 ou quelque chose comme ça (le max de ma mémoire vive), j'ai 4 Go d'installé mais 3 455 Mo d'utilisable mais ça pète quand même, je pense que la lib CHOCO que j'utilise y est pour quelque chose, je dois l'utiliser au max de ses possibilités.