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.

Cuenca

Is "Start" the name of your class that you're trying to run? Is it in the default (no) package? – Gemagemara

Yes, "Start" is the name of the class I'm trying to run (it sets up the environment), and yes it is in the default package. I tried to get packaging to work at one point but it just wasn't working out, so I left it all in the default package. – Cuenca

Possible duplicate of https://mcmap.net/q/99623/-running-jar-file-on-windows – Cooler

Whoops, guess I missed that. I'll try that solution and get back with an update. – Cuenca

That solution didn't help. It still doesn't launch. I checked CMD again and it still worked from there. – Cuenca

One note: setting java.library.path in java is useless. This property should be set only during JVM instantiation. Then it can be changed, but new value is ignored. – Unseemly

Answer 1

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.

Cuenca

I think I may have the same problem, but it is not clear how I solve the BS'ery. – Lamee

"BS'ery" adds nothing to the issue of how to actually solve this – Rode

You mention that you discovered the problem, but did not describe the specifics of the problem, and also did not describe what you did to correct the problem. – Anticholinergic

You should describe your problem and solution in more details so that others with a similar issue can benefit from your experiences. Eric posted one good solution in his answer here. – Sande

Answer 2

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

Wilcher

You sir, are a legend. I was about to rip my hair out. – Perceive

Thanks worked for me too. But still my executable jar files are visible as jar file. Looking to solve that too. – Abducent

This? #9259889 – Emulous

Answer 3

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.

Tajuanatak

Actually I noticed that the file association was "javaw.exe -jar "%1" %*" (I didn't include the path before javaw). I don't think removing the %1 would help, but I can try. EDIT:: To no avail. :/ That didn't work either. – Cuenca

Rereading your reply I realized you said to put the command into a batch file, so I did. The association I made was as such: ' "C:\test.bat" %* '. The strange thing is when the batch file ran, the output of that command (I didn't turn off echo) was this: "javaw -jar". Obviously either I used the wrong association or Windows isn't passing parameters like it should be. – Cuenca

Try %1 to be sure. Though %* shall work. (I'm on Linux, cannot test) – Tajuanatak

I just thought of that and tried it; that didn't work either. Strangest thing is that I can run other JAR files. I'm going to compile a simple test GUI JAR file and see if I can run that or not. It may be the fact that it needs outside files (it runs on the j3d jars which I keep in a folder next to the JAR). – Cuenca

Answer 4

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

Warnerwarning

This worked for me on Windows 10 where, as far as I can tell, every single GUI-based intervention has been completely removed. I copy/pasted from the above answer into a .reg file, changed the path to the EXE (mine was a different version, and a JRE instead of a JDK), and it solved the problem immediately. I wish I could give more than a single up-vote. – Transpontine

Answer 5

Prerequisite: make sure JRE(that is included in JDK) is installed.

Solution

1. Open regedit and navigate to Computer\HKEY_CLASSES_ROOT\jar_auto_file\shell\open\command

2. Add "-jar" to value data. For example, change from "C:\Program Files\Java\jdk-15.0.1\bin\java.exe" "%1" to "C:\Program Files\Java\jdk-15.0.1\bin\java.exe" "-jar" "%1"

3. Done

If problem still occurs, make sure you configure correct main class in project property.

Prude

Answer 6

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.

Punkah

Answer 7

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.

Wallinga