Por que meu arquivo JAR é executado no CMD, mas não em um clique duplo?

Então, eu escrevi um aplicativo simples da GUI 3D que pretendia que os usuários usassem simplesmente clicando duas vezes no arquivo JAR. Fiz funcionar perfeitamente antes de colocá-lo no arquivo JAR e funcionou perfeitamente NO arquivo JAR enquanto executava no prompt de comando (digitando "java -jar Modeler.jar" enquanto estava no diretório do arquivo jar). No entanto, quando clico duas vezes, nada acontece. Ele roda perfeitamente bem, sem erros no prompt de comando. Sei por experiência própria que os relatórios de falhas na inicialização não são mostrados porque o console não aparece (ou desaparece muito rápido), mas ao executar no prompt de comando, não há relatórios de falhas. Alguma idéia de por que não vai funcionar? Estou executando o Windows 7 Home Premium. Aqui está o conteúdo do arquivo JAR, se ajudar:

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

Conteúdo do MANIFEST.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: Então, depois de mexer com as associações de arquivos para usar o java.exe em vez do javaw.exe (fornecendo uma janela para as impressões), modificando um pouco o mecanismo de inicialização para imprimir o diretório de trabalho atual, descobri que o jar está sendo executado em "C: \ Windows \ system32" em vez da pasta na minha área de trabalho em que eu o coloco. Vá em frente. No entanto, mover os arquivos externos necessários para lá não ajuda em nad

EDIT 2: Tentei criar outro arquivo JAR, desta vez com um JFrame simples, com um botão que informa o diretório de trabalho atual. Pressione o botão e ele abrirá um JFileChooser (inútil). Isso funcionou com um clique duplo, não importa onde eu o coloquei no meu computador. Portanto, deve haver algo errado com o meu arquivo JAR. Começarei a solucionar problemas do meu programa novamente.

EDIT 3: O problema é exatamente o que eu pensava: não está carregando as bibliotecas corretamente quando clico duas vezes nele. A parte estranha é que, nos meus testes em que eu mostro o caminho atual e o caminho da biblioteca, a saída é exatamente a mesma, seja eu executada através do prompt de comando ou clicando duas vezes nele. Aqui está o rastreamento da pilha:

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)

O único problema é que ele está no caminho da biblioteca. Eu o configurei especificamente no programa. Agora que penso nisso, esse pode ser o problema. Eu defini assim (este foi um método que encontrei em algum lugar da internet. Não me lembro onde):

//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: Bem, depois de olhar e revisar meu código, descobri que o problema estava em alguns BS'ery envolvendo a detecção de sistemas de 64 bits em que ele carregava as DLLs erradas. Por que funcionou a partir da linha de comando e não por meio de clique duplo, não sei e provavelmente nunca vou saber, mas funciona agora com clique duplo, por isso estou feliz. Desculpe pelos problemas.

questionAnswers(6)

yourAnswerToTheQuestion