Pourquoi mon fichier JAR à exécuter CMD, mais pas sur le double-clic?

Donc j'ai écrit une simple interface graphique 3D application que j'ai prévu pour les utilisateurs d'utiliser simplement en double-cliquant sur le fichier JAR. Je l'ai eu il fonctionne parfaitement avant de les mettre dans le fichier JAR, et je l'ai eu il fonctionne parfaitement DANS le fichier JAR lors de l'exécution à partir de l'invite de commande (taper "java-jar Modeler.jar" alors que dans le répertoire du fichier jar). Cependant, lorsque je double-clique, rien ne se passe. Il fonctionne parfaitement bien avec pas d'erreurs à partir de l'invite de commande. Je sais par expérience que les rapports de plantage au démarrage ne sont pas indiqués parce que la console ne s'affiche pas (ou il disparaît trop vite), mais lors de l'exécution à partir de l'invite de commande il n'y a pas de rapports d'incident. Toutes les idées pour lesquelles cela ne fonctionnera pas? Je suis sous Windows 7 Home Premium. Voici le contenu du fichier JAR si cela aide:

Modeler.jar
|
+--*all the class files necessary*
|
+--META-INF
   |
   +--MANIFEST.MF

Contenu MANIFESTE.MF:

Manifest-Version: 1.0
Built-By: AnonymousJohn
Class-Path: bin/j3dcore.jar bin/j3dutils.jar bin/vecmath.jar
Created-By: 1.6.0_16 (Sun Microsystems Inc.)
Main-Class: Start

EDIT: Alors après de jouer avec les associations de fichier à utiliser java.exe au lieu de javaw.exe (ce qui a permis de fournir une fenêtre pour les impressions), puis de modifier le mécanisme de démarrage un peu d'imprimer le répertoire de travail actuel, j'ai découvert que le pot est en cours d'exécution à partir de "C:\Windows\system32" au lieu de le dossier sur mon bureau, je l'ai mis dans. Aller à la figure. Toutefois, le déplacement du nécessaire en dehors de fichiers, il n'aide pas quelque chose.

EDIT 2: j'ai essayé de faire un autre fichier JAR, cette fois-ci avec un simple JFrame avec un bouton qui vous indique le répertoire de travail courant. Appuyez sur le bouton et ça s'ouvre un (inutile) JFileChooser. Cela a fonctionné sur double-cliquez n'importe où je l'ai mis dans mon ordinateur. Donc il doit y avoir quelque chose de mal avec mon fichier JAR. Je vais commencer le dépannage de mon programme.

EDIT 3: Le problème est juste que je pensais que c'était: il n'est pas le chargement des librairies correctement quand je double-cliquez sur elle. Ce qui est curieux, c'est que dans mes tests où j'affiche le chemin d'accès actuel et le chemin de la bibliothèque, le résultat est exactement le même si je le lance via l'invite de commande ou via un double-clic. Voici la trace de la pile:

java.lang.UnsatisfiedLinkError: no j3dcore-d3d in java.library.path
  at java.lang.ClassLoader.loadLibrary(Unknown Source)
  at java.lang.Runtime.loadLibrary0(Unknown Source)
  at java.lang.System.loadLibrary(Unknown Source)
  at javax.media.j3d.NativePipeline$1.run(NativePipeline.java:231)
  at java.security.AccessController.doPrivileged(Native Method)
  at javax.media.j3d.NativePipeline.loadLibrary(NativePipeline.java:200)
  at javax.media.j3d.NativePipeline.loadLibraries(NativePipeline.java:157)
  at javax.media.j3d.MasterControl.loadLibraries(MasterControl.java:987)
  at javax.media.j3d.VirtualUniverse<clinit>(VirtualUniverse.java:299)
  at javax.media.j3d.Canvas3D.<clinit>(Canvas3D.java:3881)
  at ModelPreview.<init>(ModelPreview.java:51)
  at Modeler.<init>(Modeler.java:76)
  at Modeler.main(Modeler.java:1227)
  at Start.main(Start.java:92)

Seul problème est qu'il EST dans le chemin de la bibliothèque. J'ai spécifiquement définie dans le programme. Maintenant que j'y pense c'est peut être le problème. Je l'ai mis comme (c'était une méthode que j'ai trouvé quelque part sur internet. Je ne sais plus où):

//above was code to get newPath based on the Operating System.
//all this code is set in a try-catch phrase.
//reset the library path
System.setProperty("java.library.path", ".\\bin\\natives" + newPath + ";");
//make sure the ClassLoader rereads the NEW path.
Field f = ClassLoader.class.getDeclaredField("sys_paths");
f.setAccessible( true );
f.set(null, null); //ClassLoader will automatically reread the path when it sees that it is null.  

EDIT FINAL: eh Bien, après la recherche et de relooking à mon code, j'ai découvert que le problème était dans certains BS'ery impliquant la détection de 64 bits des systèmes où il était en train de charger le mauvais dll. Pourquoi cela a fonctionné à partir de la ligne de commande et non pas par un double clic, je ne sais pas et ne saurai sans doute jamais, mais qu'il fonctionne via double-cliquez maintenant, donc je suis heureux. Désolé pour les ennuis.