java applications as executable jars vs exe files.

[Michael Wiezik]

Me and me friend create a desktop application for small companies. He's not a programmer, but a customer. he wants the application as an *.exe file, because of the following:

- you don't have to install any java VM to execute such application;
- every commercial application has a form of *.exe file + additional files
- potencial client is totally laic and doesn't know what java VM is, therefore you cannot expect him to do a sophisticated installation process including installation of java VM;
- if an application is in *.jar form and a user has installed, f.e. winrar, double-clicking on the jar file doesn't executes the jar;

I believe that making *.exe files is not good because of the following:
- There's no such official SUN tool for doing that; there are only third-party products and you cannot be 100% they will create *.exe files
- Making *.exe from java application is totally against the fundamental java rule: "write once, run everywhere";
- an exe file generator probably includes the java VM and a part of the SDK to the exe file; it's like including Corel Photo Paint to every picture in picture gallery;

Therefore, I've got a question. Is it a typical procedure to create *.exe files for commercial distributions? Assume customers are not java programmers; if You want to sell them something, it may require up to two mouse clicks to run.

Thnx in advance for reply.

[JulianInactive KennedyInactive]

Hi Michal,

In my experience standard commercial practice for application deployment takes one of 3 forms:

Installation Wizard - user-friendly GUI-based installation software that walks a user, who may have no technical background, through the steps of installation. This approach is suitable for the IT literate layperson (i.e. someone who's not scared of mice )

On-site Installation Service - A friendly chap (or chapess) from the software vendor turns up at the customer's site and performs the installation. This approach is most suited to those without either the time, interest or IT knowledge to do a self-installation. Could also be remote these days, I guess, with appropriate permissions.

Custom Self-Installation - This is basically what we do when we download, install and configure the J2EE SDK, application server, database software, firewalls and so on. Obviously this is best suited to the technically minded user or the enthusiastic amateur.

The real point here is that what is important is how you package your distribution and the services you provide to your new customers.

To answer your friend's points:

If you're writing apps in Java, executing them without a JVM is a bit of a nonsense. If you don't want to use a JVM, why not turn to the dark side and use C#? I've heard it's not that bad. It could make things awkward, however, if your app needs to run on Unix or a Mac, for example.

The assertion that every commercial app has an .EXE and a set of related files is simply not true. It is, however, understandable that an IT literate layperson with limited experience of only Windows applications might hold that view.

I hope I've answered the point about appropriate deployment to laic clients adequately above.

So don't double-click on it then! There are better ways of launching applications, certainly from a client point of view, than expecting them to click on the filename in explorer. Why not include a simple launcher .EXE or a .BAT file that can be wrapped up in a pretty desktop shortcut, if this is a real issue? How likely are these technophobic users to be using Winrar anyway?!

Hope this is useful.

Jules

[ August 08, 2004: Message edited by: Julian Kennedy ]
[ August 08, 2004: Message edited by: Julian Kennedy ]

[Jack Kay]

Originally posted by Julian Kennedy:
If you don't want to use a JVM, why not turn to the dark side and use C#?

Well I guess that makes me Darth Vader lol, or that that guy with spikes coming out of his head, that would be interesting...

But as you were saying Michal, I believe that *.exe is the way to go. Then you could have 3 versions of the same program, except for different operating systems. Like, you could build the Java program (.class), and then use a cool program that instantly converts that into 3 different executables for every operating system you want it to run on!

Because I like *.exe better than *.class because people always have problems with using the command prompt to launch my programs that I've created.

[Michael Wiezik]

Hi Jack,
I've read some forums and materials on the net. I've realised the problem with desktop applications is rather not whether they should be launched by *.exe file, *.cmd script or executable jar, but is it proper to add a whole VM to *.exe file to make it totally independent from java environment.
Once you have installed java VM, you can write *.bat or *.cmd launcher, executing command

java -jar applicationName.jar

to prevent client launch an application from the command line. So, the main problem is how to provide a VM to client's machine.
As I've searched the net, I could say to things (correct me if I'm wrong):

None of well-known native compilers (creating exe file), including Borland JBuilder native compiler, adds whole VM to exe file; an exe file is just a launcher, just as *.bat file is

You can create an installer to your project (I've found "Install anywhere" software), which installs a VM before an application. Therefore, the problem is solved in the most elegant way you could imagine.

Thanx both for reply.

[Michael Wiezik]

Hi Julian, do you check your private message box? Please reply if you find some free time. Thnx in advance.

[Jessica Sant]

just as a though -- its nice if you can keep your discussions about a topic out in the public rather than in private messages (if you don't mind) -- that way our archive becomes even better and next time someone is looking for this topic -- maybe this thread will have the answer!

[Michael Wiezik]

its nice if you can keep your discussions about a topic out in the public rather than in private messages

Hi Jessica,
my private message to Julian is about his job seeking in the U.K. (as he wrote in his post). It's nothing private at all and it's not a secret, but it has nothing with the subject of the main post. So, I decided not to post it on coderanch.
Have a nice day .

[Jessica Sant]

Originally posted by Michal Wiezik:
my private message to Julian is about his job seeking in the U.K. (as he wrote in his post). It's nothing private at all and it's not a secret, but it has nothing with the subject of the main post. So, I decided not to post it on coderanch.

not a problem at all! and good luck with the job seeking. It's always good to make connections in the industry. I just wanted to make sure that valuable discussion about packaging didn't go underground!! thanks!

[JulianInactive KennedyInactive]

Guys, guys! Don't fight over me; there's plenty to go round!

Jules

[Dom King]

It does not appear that there is any real and complete Java-to-.EXE tool available yet for Windows. Either the tools make a "fake" .EXE that just launches (or installs) the JRE along with your application (BTW, this is basically the same approach as VB or VB.NET's Make .EXE feature), or the tool compiles it to 100% native code but still requires the JRE for the classes you really need, like AWT, Swing, or almost anything new. It seems that practically all Java tool vendors and Sun are convinced that option 1 satisfies/pacifies most developers/users, and that option 2 does not have a market that justifies the tremendous investment in both native compiler and independent library development. Curious, what do you think of the practicality/viability of option 2?

If you're waiting for option 2, you may want to consider NewJ Library in the meantime. It's not (yet) a turnkey solution, but it does allow you to use the core Java API in 100% native C++ apps without requiring any JRE. (Yes, that was a plug.)

NewJ info: http://www.pure-native.com/newj.html