Why does my JAR file execute at CMD, but not on double-click?

Question

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:

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

Contents of 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: 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.

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.

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:

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)

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):

//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: 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.

Answer 1

Ok, so I was stuck on this exact issue for over a week now (it has been for a side project for which I could only devote a few hours a day).

This happened on my desktop, but for some reason wouldn't happen on the laptop.

After looking around, I found this answer and I thought I'd share it for people who are like me, found nothing useful in the accepted answer here. Credits go to anonymous Stack Overflow user, whom username I've lost in all the excitement.

As mentioned by some other answer somewhere to an seeming unrelated issue, use this little program to associate your JAR files to the 64 bit version of java:

http://johann.loefflmann.net/en/software/jarfix/index.html

Save the program somewhere and run it from command line with the parameter /64: c://path//jarfix.exe /64

Nothing else worked for me, but this was like magic. :)

Answer 2

The JAR is executable from CMD. That means the JAR itself is formed correctly. Good.

The only reason to fail now is that double-click produces not a right command. Expected command, as you correctly said, is

java -jar Modeler.jar

But when you associate javaw.exe with a JAR extension, I suspect it executes

javaw Modeler.jar

It is easy to check: make a javajar.cmd file, containing the following

javaw -jar %*

and associate it with JAR. If you app starts OK, I'm right. Otherwise, sorry.

Answer 3

I got fed up with not being able to modify file associations in Windows 7 Control Panel and edited the registry (NOTE: it's not a bad idea at all to set a restore point before proceeding if you think there's ANY chance you may screw up)(I neither set restore point nor screwed up):

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\jar_auto_file]
@=""
"EditFlags"=hex:00,00,00,00

[HKEY_CLASSES_ROOT\jar_auto_file\shell]

[HKEY_CLASSES_ROOT\jar_auto_file\shell\open]

[HKEY_CLASSES_ROOT\jar_auto_file\shell\open\command]
@="\"C:\\Program Files\\Java\\jdk1.7.0_60\\bin\\javaw.exe\" -jar \"%1\" %*"

This assumes that .jar files have (Default) value jar_auto_file. If not do this:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.jar]
@="jar_auto_file"

p.s. One problem I found in the registry was that jarfile was associated with Netbeans, Chrome, and java.exe as well as with Applications\java.exe. I deleted that entire node (after exporting it, just so I could put it back if it was essential; it wasn't). Now there is NO jarfile in my registry and all .jar files execute as before.

This manifests itself by showing more than one file type associated with .jar files in Control Panel. You want this:

If there's more than one item shown in Recommended programs, search registry for jarfile and (export first, then) delete that node:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.jar

Answer 4

Just to put my two cents in, I had this problem and it was caused by something-or-other in the manifest, I suppose. I resolved it by generating the executable JAR in a different manner:

Previous developer generated the Runnable JAR from Eclipse (right-click project -> Export... -> Runnable JAR) and this worked fine for everyone. Then I came along and generated the runnable JAR by configuring a Maven plugin ("assembly") in the pom.xml and so a classic Maven build would produce the runnable JAR.

This worked nicely for me (from cmd and by double-clicking) but not for the end-users (who could still run the tool from cmd, but not by double-clicking the JAR).

I generated the runnable JAR from Eclipse and now everyone is happy again. Not sure why the maven-generated JAR wasn't ok to run by double-clicking, but I can't be bothered to investigate further now that the job is done. Hope this half-advice helps someone.

Answer 5

I had same issue with .jar files after trying everything i realized that I have more than one versions of Java installed. Removing the unnecessary versions solved my issue. May be because the .jar was confused between different versions of JRE.

Answer 6

Just so that the answer to the question is clear to anyone passing by, I'll put my solution here (I couldn't before because of the 8-hour rule):

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.