title: Why does my JAR file execute at CMD, but not on double-click?
body: <p>So I've been writing a simple 3D GUI application that I intended for users to use simply by double-clicking on the JAR file. I got it working perfectly before putting it into the JAR file, and I got it working perfectly IN the JAR file while running from command prompt (typing "java -jar Modeler.jar" while in the directory of the jar file). However, when I double-click it, nothing happens. It runs perfectly fine with no errors from command prompt. I know from experience that crash reports on start-up are not shown because the console doesn't appear (or it disappears too fast), but when running from the command prompt there are no crash reports. Any ideas as to why it won't work? I'm running Windows 7 Home Premium. Here are the contents of the JAR file if it helps:  </p>
  
  <pre><code>Modeler.jar
  |
  +--*all the class files necessary*
  |
  +--META-INF
     |
     +--MANIFEST.MF
  </code></pre>
  
  <p>Contents of MANIFEST.MF:</p>
  
  <pre><code>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
  </code></pre>
  
  <p>EDIT: So after messing with the file associations to use java.exe instead of javaw.exe (thereby providing a window for print-outs), then modifying the startup mechanism a little to print out the current working directory, I discovered that the jar is running from "C:\Windows\system32" instead of the folder on my desktop I put it in. Go figure. However, moving the necessary outside files there doesn't help anything.  </p>
  
  <p>EDIT 2: I tried making another JAR file, this time with a simple JFrame with a button in it that tells you the current working directory. Press the button and it opens a (useless) JFileChooser. This worked on double-click no matter where I put it in my computer. So there must be something wrong with my JAR file. I'll start troubleshooting my program again.  </p>
  
  <p>EDIT 3: The problem is just what I thought it was: it's not loading libraries correctly when I double click on it. The weird part is that in my tests where I display the current path and library path, the output is exactly the same whether I run it via command prompt or via double-clicking on it. Here's the stack trace:</p>
  
  <pre><code>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&lt;clinit&gt;(VirtualUniverse.java:299)
    at javax.media.j3d.Canvas3D.&lt;clinit&gt;(Canvas3D.java:3881)
    at ModelPreview.&lt;init&gt;(ModelPreview.java:51)
    at Modeler.&lt;init&gt;(Modeler.java:76)
    at Modeler.main(Modeler.java:1227)
    at Start.main(Start.java:92)
  </code></pre>
  
  <p>Only problem is that it IS in the library path. I specifically set it in the program. Now that I think about it that may be the problem. I set it like so (this was a method I found somewhere on the internet. I don't remember where):</p>
  
  <pre><code>//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.  
  </code></pre>
  
  <p>EDIT FINAL: Well, after looking and relooking at my code, I discovered the problem was in some BS'ery involving the detection of 64-bit systems where it was loading the wrong dll's. Why it worked from the command-line and not via double-click I don't know and will probably never know, but it works via double-click now, so I'm happy. Sorry about the troubles.</p>