I recently created a jar file out of a program I'd made using the command prompt. I included a manifest file and since I wasn't sure what other files to include I added the entire folder my program was in. The jar ran perfectly on my computer. However, when I tried e-mailing it and running it on a different computer I was told the main class couldn't be found. How do I fix this?
Including a folder in the jar file sounds like a dubious proposition (or did you mean the contents of the folder?)
Have a look at the jar file section of the Java Tutorial, particularly "Working with Manifest Files". It explains how to set the Main-CLass and Class-Path headers, which I think are what you need to use.
Joined: Feb 19, 2006
Sorry, I was unclear. I included the entire contents of the folder my program was in, not the folder.
I used the command jar cmf manifest.txt myProgram.jar * in command prompt.
My manifest file was Main-Class: mainClass (blank line)
As a test I sent my folder with the program in it to the trash can along with the jar. Then I downloaded the jar I e-mailed myself and ran it. It still worked. However, on a different computer with java installed I'm told the main class cant be found.
Need more information. What does your manifest file look like? How is it being run on the other system (e.g. command line, double click)? Have you tried running it another way, for example running it from the command line successfully and failing on a double click could indicate a problem with the association in the OS. Creating an executable JAR file is pretty simple really, it's just common stupid mistakes that get people, including myself.
When I tried to run the jar from the command line on another Windows machine, I got an UnsupportedClassVersionError (Unsupported major.minor version 49.0). It turns out the program was compiled with Java 1.5, but the destination machine has a 1.4 JRE.
So I made a simplier test program (just a JFrame) that doesn't use any new 5.0 features and made a new jar. Then I recompiled using -source and -target options of 1.4, and made another new jar. As expected, the 5.0 jar failed on the destination machine. The 1.4 jar worked when running from the command line, but double-clicking on the jar just quickly opened and closed the Command window. So I re-associated the jar file type to open with javaw (to suppress the Command Prompt window), and this finally corrected the problem.
Edward: I would be very interested to know if this helps with your situation.
Originally posted by Ken Blair: ... Creating an executable JAR file is pretty simple really...
Maybe. But getting it to run consistently on Windows machines is pretty frustrating.
After getting the jar to work on a test machine (see above), I tried sending it to a regular user. They report the following error when attempting to run the jar: "Java Virtual Machine Launcher: fatal exception occured. Program will exit."
I've seen some threads on the Sun boards about this, but no answers. I also found this thread here in Java Beginners, but the proposed solution doesn't look promising for any wide-scale deployment (and I don't have a jar inside the jar).
I'm thinking it might be this bug, but it's odd that the jar works fine on a test machine (supposedly configured the same way with Java 1.4.2 and associating jar files with javaw). [ July 21, 2006: Message edited by: marc weber ]
Joined: Jul 15, 2003
It still usually boils down to the system being configured improperly or an application doing something it probably shouldn't. An executable JAR should run fine on any machine that's properly configured. Of course, the properly configured part is the key. In many cases it's probably enough to simply have them install the latest version of the JRE. For other cases I think that's when it's time to look at a Java-aware installer. We've all grown used to needing installers for applications, why does Java seem to be the exception?
Originally posted by Ken Blair: ...In many cases it's probably enough to simply have them install the latest version of the JRE...
Yes, but unfortunately this is a huge roadblock in many business environments. They just upgraded a few months ago to 1.4.2, and users are prohibited from downloading/installing new software.
(Note: This is not a live project I'm working on. I'm just pursuing this out of my own curiosity.)
Joined: Jul 15, 2003
I understand your point, but is your application not new software to begin with? If they can install your new software then what's to keep your software from using a Java-aware installation tool to provide a compatible JRE if one is necessary? Software bundled with a compatible version of DirectX as an example is pretty common in my experience. I don't view bundling a JRE with it any differently.
Originally posted by Ken Blair: ... If they can install your new software then what's to keep your software from using a Java-aware installation tool to provide a compatible JRE if one is necessary? ...
This is a corporate environment. It's not rational. (Think of Dilbert's Mordac character, Preventer of Information Technology, who "believes his mission is to make it as difficult as possible for employees to use their computers or the network.") If this were a "real" application, we would probably need to bury the code inside a Lotus Notes database to get it out there. But as I said, I'm just pursuing this out of my own curiosity to see how viable an executable jar really is on Windows machines.
Okay, to be more specific (or honest)... Let's say I wanted to write a silly little app as a joke -- like a "Project Cost Estimator" that basically just spits out random numbers -- and send it to a few people as an email attachment. For something on that scale, it would be nice to send a small "executable" file without a whole new runtime environment.
Joined: Jul 15, 2003
Then it still comes back to them having a properly configured machine and writing code for the oldest JRE you're willing (or forced) to deal with. I mean, if I compiled a C++ program that required DirectX 9 and they hadn't upgraded yet I'd have the same problems. The solution is to either update the platform or write applications that don't require DirectX 9.
In a more 'serious' application you'd have to update the platform. For your purposes you'd have to stick to what they've got available. Of course, nothing can help you when their system isn't properly configured. But that applies to anything and you can always include a run.bat for those with associations that aren't setup right.