Best Java .exe Creator?

> Just wondering - what would be a good, platform

> independant way of packaging a java application so

> that somebody with a non-technical background could

> use it with ease?

An "executable" JAR file. With the main-class attribute set and JAR files being associated with javaw.exe in Windows (which the Java installer does nowadays IIRC), a double-click is all that's necessary to run a JAR.

Or Webstart, which also uses JARs though.

CeciNEstPasUnProgrammeura at 2007-7-8 22:51:58 >

> > java is platform independent, .exe is not

>

> Just because you distribute a Java application as a

> native executable for a certain platform doesn't

> change the platform independence of the Java

> application. It's still perfectly platform

> independent.

What? I don't get it?

kajbja at 2007-7-8 22:51:58 >

> Just because you distribute a Java application as a

> native executable for a certain platform doesn't

> change the platform independence of the Java

> application. It's still perfectly platform

> independent.

But the deployed package isn't distributable. You'd have to recompile.

CeciNEstPasUnProgrammeura at 2007-7-8 22:51:58 >

> Don't say that. Someone has to yell "the emperor has

> no clothes" the next time you try to show off as The

> Great OO Designer.

Plenty of people are ready for that post. You'll need to apply for that position.

You, on the other hand, have offered nothing of value here for years except for your pompous diatribes about object-oriented purity. As if you'd recognize it if it bit you in the ***.

%

duffymoa at 2007-7-8 22:51:58 >

since JAVA is platform independent, hence no need to search for an exe file, it runs on JAR extension. only one exe file needed while running on Windows environment is java.exe. if u really need to create an exe file, it is priorly to create an installer for a windows based system not containing JRE. the motto is to bundle the JRE with your application, as it is done with netscape.

for this purpose there are various IDE available on the net ie. ECLIPS.

srivastava@univa at 2007-7-21 16:45:47 >

Re: the platform independence of .exe files:

There are different levels of platform independence here. One is the C/C++ level, in which code can be recompiled for different target platformss, with (hopefully, although seldom in practice) no changes to the source.

Then you have the level that Java bytecode provides, in which the object code itself can be deployed on mulitple target platforms.

This latter level of platform independence is important, because it can greatly simplify deployment. It's not trivial or non-existent. I'll say that again with more emphasis: deployment issues are not trivial.

But sadly, when people discuss compiling Java to .exe files (i.e., a single target platform to the exclusion of other target platforms), certain annoying, willfully dim people like to make two flawed arguments against it.

The first flawed argument is to ignore this latter level of platform independence. Such as:

> Just because you distribute a Java application as a native executable for a certain

> platform doesn't change the platform independence of the Java application.

> It's still perfectly platform independent.

This is a flawed argument as described above. Yes, the Java source code is still platform independent in the limited first sense, but the second level of platform indepenence has been thrown away. It's not "perfectly" platform independent. It's partially platform independent, compared to the level of platform independence that Java normally provides.

The second flawed argument is to insinuate that anyone who opposes preserving the greater platform independence is panicking, or a rigid purist:

> Or do you actually believe that generating a native executable will somehow

> contaminate the Java application with germs so it's no longer platform independent?

But of course, nobody is suggesting that the original source has (necessarily) been compromised. And nobody has used a word like "contaminate". They are simply pointing out that a major advantage of Java is being thrown away.

This is basically an ad hominem attack.

This false argument mixes the two together.

> The principle of the Java platform independence is not affected by the ability to produce

> native executables for certain platforms. I said this because some people still seem

> to believe native executables are contrary to this principle.

Of course, a native executable does effect the platform independence, because that native executable is itself not platform independent -- so the platform independence of the deployed object code is lost, and the independence of the project as a whole is lessened. (The independence of the source code isn't, necessarily, but nobody is saying that it is.)

And:

> What is so terribly wrong with offering your Java app as a set of OS-specific downloads

> so that any person who has no clue what Java is all about could install your application

> on that one particular operating system that he or she uses and not care about

> Java-enabling it? You know, so that it just works for him or her, right away?

Note that he starts with the second false argument, trying to make any opponents sound like extremists. Nobody is saying that it's "horribly wrong" -- it's just throwing away one of the major advantages of Java. Which isn't wrong, but by throwing such an advantage away it reduces the advantage of choosing Java for the implementation of your project.

Then he goes on to the first argument, ignoring the fact that the latter kind of platform independence is even an option. He also kind of mis-represents the independence: "not care about Java-enabling it? You know, so that it just works for him or her, right away?", as if simply running a Java program were extremely painful, and almost an act of programming in itself.

As I said earlier: I'm sure there are cases where native executables of Java source code are a good thing, but most of the time when people ask about it (on these forums at least) it seems to be because of newbies who think they have to generate an .exe for any program. And as I said one of the many previous times this has come up, I suspect those cases are relatively limited, since once you've gone that far then going even further and switching to C++ and making even more tuned, less portable applications becomes more attractive.

paulcwa at 2007-7-21 16:45:48 >

> The first flawed argument is to ignore this latter

> level of platform independence. Such as:

>

> > Just because you distribute a Java application as a

> > native executable for a certain

> > platform doesn't change the platform independence

> > of the Java application.

> > It's still perfectly platform independent.

>

> This is a flawed argument as described above. Yes,

> the Java source code is still platform

> independent in the limited first sense, but the

> second level of platform indepenence has been thrown

> away. It's not "perfectly" platform independent.

> It's partially platform independent, compared

> to the level of platform independence that Java

> normally provides.

A pure Java application will always be platform independent and that's because it's written in Java. That's because one Java runtime format (bytecode) has been made ubiquitous (JVM's available on many platforms).

The above is the definition of Java platform independence. It can never be taken away from a pure Java application. So it doesn't matter how many different runtime formats are produced, the application will remain platform independent.

It is possible, even easy, to render a Java application not platform independent.. It's just to write parts of it in languages other than Java (using JNI). This will make a Java application not platform independent. Generating a native executable from a pure Java application won't.

paulcwa at 2007-7-21 16:45:48 >

> The second flawed argument is to insinuate that

> anyone who opposes preserving the greater platform

> independence is panicking, or a rigid purist:

>

> > Or do you actually believe that generating a native

> > executable will somehow

> > contaminate the Java application with germs so it's

> > no longer platform independent?

>

> But of course, nobody is suggesting that the original

> source has (necessarily) been compromised. And

> nobody has used a word like "contaminate". They are

> simply pointing out that a major advantage of Java is

> being thrown away.

No advantage has been thrown away by producing a native executable. On the contrary several advantages are possible (see the Excelsior home page).

There are technical, administrative, financial and legal differences between distributing a bytecode and a native executable. This is a decision that can be made without any concern about the platform independence of the application. It's not affected.

paulcwa at 2007-7-21 16:45:48 >

Sure there's an advantage being thrown away. The advantage is that you don't have to think about that junk. You make one executable and it just works across platforms. That advantage may be a big reason you chose Java to begin with. And it's probably the typical use of at least 95% of the Java deployments out there.

When you start making multiple executables, you put yourself in roughly the same position (process-wise) than if you didn't have a portable (bytecode) executable to begin with.

And if you make only a native executable, then you certainly have affected the platform independence of the deployed object code.

paulcwa at 2007-7-21 16:45:48 >

> Yes a native executable is restricted to a certain

> platform but that's kind of the whole idea. You do it

> for a reason.

Assuming you actually do it for a good reason, yes. But doing it because you don't realize that portable bytecode is an option (in fact, the typical option) isn't a good reason.

There can be reasons to do this, but I haven't seen them come up in practice in 10 years of coding Java professionally.

> The project (whatever that may mean) is not effected

> at all. The bytecode executable can be deployed as

> readily as before, even on platforms already targeted

> by a native executable of the same application.

Sure it's effected. Before, you had a single executable you deployed everywhere. With a single native executable, you have a single executable you can deploy in only one platform. With multiple executables, you now have to manage multiple executables, many (or all) of which only go on one platform each. This affects the project in a huge way, logistically.

By the way here's a definition of "project":

-- an individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim : a research project | a nationwide project to encourage business development.

-- a school assignment undertaken by a student or group of students, typically as a long-term task that requires independent research : a history project.

-- a proposed or planned undertaking : the novel undermines its own stated project of telling a story.

paulcwa at 2007-7-21 16:45:48 >

Well paulcw I think I stop there. I've presented my view and the rest will just be nagging.

But to summarize my view:

A pure Java application is platform independent. To produce a native executable for a certain platform has technical, administrative, financial and legal consequences, BUT the application still is as platform independent as before. No restriction what so ever has been put on it. The decision to distribute a native executable is unrelated to the platform independence quality of Java.

paulcwa at 2007-7-21 16:45:48 >

> So when a person makes the (completely correct) point

> that a .exe is not itself platform independent:

>

> java is platform independent, .exe is not

>

> Don't confuse the issue by suggesting that an .exe

> actually is platform independent:

Well okay let's nag -:)

That statement in itself is completely cosher. I've never contested it.

But it's a discussion entry and it was made in the context of this thread. I interpreted it to mean that generating a .EXE is somehow in opposition to the Java platform independence.

Maybe I was wrong in assuming that but so what, no harm done really.

> > Just because you distribute a Java application as a

> > native executable for a certain

> > platform doesn't change the platform independence

> > of the Java application.

> > It's still perfectly platform independent.

>

> At least, not without also acknowledging that the

> platform independence really is lost if the .exe is

> the only executable produced.

This is the last time I say this now. In my view the application is still platform independent untder that circumstance. Even if the only runnable distribution ever produced is a native executable won't change anything. The application will remain platform independent because it's written in Java..

> And especially stop the ad hominem attacks:

I often spice up my replies but that's just to get a discussion going. It's my style and I mean no harm.

> And, again, how often do you write real, compiled,

> executed Java code, and how often do you also make

> and distribute native executables?

You're looking for proof in numbers?

Well, lets put it this way. If Java is to succeed as a language for commersial applications on the desktop then native executables are a must. When it comes to open source, in-house applications, hobby projects etcetera, then it's probably less important.

paulcwa at 2007-7-21 16:45:48 >

> well i missed it, well did you people reached a

> conclusion.

>

> For what i meant is that, creating a jar, you can run

> it any where, no need to compile it again to run it

> in another operating system.

That isn't what we are discussing :)

kajbja at 2007-7-21 16:45:52 >

Oh d a m n a geek fight has broken out.

could some just please help me: where do i type these commands to make a JAR? the IDE that i'm using atm does build JARs but it doesn't set a Main-Class so i always get an error whenever i double-click on the built JAR.

Message was edited by:

Alex1989

Alex1989a at 2007-7-21 16:45:52 >

> Well, lets put it this way. If Java is to succeed as

> a language for commersial applications on the desktop

> then native executables are a must. When it comes to

> open source, in-house applications, hobby projects

> etcetera, then it's probably less important.

I'd take issue with this. Java is already a success for commercial applications on the desktop - in the very "in-house" applications that you wave away. There's a lot of money in bespoke systems.

Shrink-wrapped software is very visible - and needs the kind of seamless integration that "native" languages tend to offer, but I wouldn't be remotely surprised to find that it was the smaller of the two markets.

D.

dcmintera at 2007-7-21 16:45:52 >

> > In a command shell, of course.

> >

> > That's a DOS window if you're using Microsoft

> > Windows.

>

> <nitpick>

> Command Prompt:

> http://www.interact-sw.co.uk/iangblog/2004/03/04/notdo

> s

> </nitpick>

i've already tried the command prompt and it gives me this error: "'jar' is not recognized as an internal or external command, operable program or batch file."

Alex1989a at 2007-7-21 16:45:52 >

> > > In a command shell, of course.

> > >

> > > That's a DOS window if you're using Microsoft

> > > Windows.

> >

> > <nitpick>

> > Command Prompt:

> >

> http://www.interact-sw.co.uk/iangblog/2004/03/04/notdo

>

> > s

> > </nitpick>

>

> i've already tried the command prompt and it gives me

> this error: "'jar' is not recognized as an internal

> or external command, operable program or batch file."

you might have not installed JRE .. try it like this....

c:/><file name>.jar

srivastava@univa at 2007-7-21 16:45:52 >

> you might have not installed JRE .. try it like

> this....

> c:/><file name>.jar

I have installed JRE 6. when i try c:/><file name>.jar it gives me this: "'C:\Documents' is not recognized as an internal or external command, operable program or batch file" :/

Alex1989a at 2007-7-21 16:45:52 >

> > Just wondering - what would be a good, platform

> > independant way of packaging a java application so

> > that somebody with a non-technical background

> could

> > use it with ease?

>

> Java Web Start or a Java aware installer (Install

> Anywhere for example).

I agree with this. With JWS you can setup a webpage that can check for the JRE and direct them to a page where it can be downloaded. Once that's done downloading and launching the application is one click of a button.

Of course JWS doesn't work for everyone. Maybe they don't have internet access, or you don't want to maintain a webpage, or you don't want to run your application through JWS and deal with the security. In those cases I'd use a Java aware installer that is capable of installing the JRE if needed and keep things simple. Sure, it's more work for you to have an installer for each OS but chances are you know what you're doing and can deal, the user may not be able to.

kablaira at 2007-7-21 16:45:57 >

Actually...you know what would be a really appropriate use of a native compiler?

@Excelsior guy: you can start paying attention again

J2ME code. Handsets are so restricted, and developing for them is so idiosyncratic, that in that field apparently even Java developers create lots of different target builds for different platforms anyway. So in that field the advantage of portable object code is pretty minor to begin with.

Secondly, some handsets do BREW, some do J2ME, some may do both, but it seems that most do one or the other but not both. If there were a native Java compiler that produced BREW code, then a shop could (ideally, anyway) keep their whole codebase in Java, and produce object code for both BREW and J2ME devices.

OK, Excelsior guy. You've heard it. If you're not already doing this, start doing this, and pay me royalties. Now get cracking!

paulcwa at 2007-7-21 16:45:57 >

> 1) Again, you didn't answer the question. My major

> point in asking this was to determine whether this

> has any practical implications for you or whether

> it's purely theoretical for you. It seems to be the

> latter.

I try to keep discussions principal. It's not that interesting what the individual programmer do really. And it's my principal view that producing a native executable doesn't in any way limit the platform independence of the application itself (the application being "source & rights" in my view).

But if you ask if I've personally been distributing a native executable the answer is no. But I have participated in developments where this has been the case and when I'm closer to distribution of my own pet-project I certainly will.

For me, native executable deployment beats bytecode big time. It's so much less trouble.

mlka at 2007-7-21 16:45:57 >

Before I give my 2cents in this thread, I want to mention that I've only gotten up to post #38 before writing this - so please forgive my stepping on anyone elses toes by re-inventing their post.

It appears to me to be a case where someone goes out of their way to buy a vehicle - I am a car guy, BTW - that can "allegedly" go anywhere (on/off road that is) and then proceeds to place wheel and tire combinations on it that effectively leave it as a "can't go much of anywhere" vehicle, because ground clearance is reduced, and tires lack traction and ability to protect the wheel and suspension components from potholes due to incorrect tread design and insufficient sidewall depth.

Java was developed to be platform independant for some very good reasons and alot of work went into the language to make it capable of doing that to about as great a degree as is probably possible. Why degrade that?

MS has indeed made their O/S ever present, obviously to make money initially on the product itself, but also by taking the long view of things ... by generating market forces that are self-perpetuating - so just about everything runs on Windows.

We "want" that same self-perpetuation for the Java platform. We do that by - in a sense - forcing others to get a JRE.

Now I know that in a couple of other recent threads I myself have asked about a "good" Java .exe maker. I thank the poster of early on in this thread for posting the link to Excelsior Jet, because it filled in a few gaps in my own understanding of the various offerings out there. But my opinion has not changed on that one either ... it seems they are all either too expensive or incomplete.

~Bill

abillconsla at 2007-7-21 16:45:57 >