I wrote a java program/application and I'm trying to combine all the .class files into one .exe file.

I want to have a convenient double-clickable EXE file to launch the program without the user having to handle .java file associations.

Recommended Answers

All 23 Replies

You don't, you create executable jar files (not "exe"s).

http://java.sun.com/docs/books/tutorial/deployment/jar/index.html

Edit: And, if you want a "real exe" (i.e. a native executable), then use a language designed to produce a native executable (which Java is not).

If you insist on doing something that will negate all the "advantages" gained by using Java and produce a native executable with it, then Google for some thrid party tools that are designed to do this (there are plenty of them). It is not a recommended course of action, though, so your on your own.

I had a customer once who wanted .exe files instead of .jar files *sigh* guess how happy he was when he found out his program didn't work so well in Linux :P

anyhow, an easy-to-use tool to create an .exe from your .jar is NativeJ, an even easier approach to your question would be the search function, since this question has been asked (and answered) a lot of times before.

There are two ways you can do this. One of them is as described above to pack all .class into one executable jar file which can then be run on any PC that has JRE installed. This can be done through the use of a manifest file (you need to write the main class name into the manifest file so that it knows which class to run). You can lookup this procedure on either the Sun's site or any site that has information for creating executable JAR's. One risk that this procedure runs is that you are basically shipping all your class files which can be potentially decompiled and your source code be exposed to other parties. So if you have the concern of keeping your source code closed you can use the second method mentioned here.
The other method is to use some kind of Java-to-EXE converter software which would take all the class files and optionally the manifest file as input and produce an EXE file as an output. Some of them take theexecutable JAR as input. Shipping an exe file essentially keeps your source code protected. You can also optionally have JRE embedded into the EXE creator during input so that if the target PC does not have JRE installed already you can do it automatically. One such tool is the JexePack which we use, but since this is a licensed s/w you need to purchase copies of it from the vendor.

Native executables can be decompiled just as easily as class files. This is a "non-argument".

Edit: And don't ask me how, because I won't tell you. I am not here to instruct people on reverse engineering. I will say this though, "Just because you don't know how to do it, does not mean that it cannot be done."

Hi,
I was recommending just a course of action to a person who seems to be in need. But you look to be insterested in restricting the power of langauges so much that nothing other than the opinions you have seem to be valuable to you. We are certainly not here to discuss how much you and I know, but to solve each others problems. I have just expressed my opinion and the original poster can as well not take my opinion if he feels so. But atleast I offered a solution which you did not even try to. You seem to look so busy in showing off your knowledge.

No, I was refuting your statement of "Shipping an exe file essentially keeps your source code protected".

You are more than welcome to help, but posting false information (knowingly or not), does more damage than good.

Edit: And that statement that was being refuted is definately not an opinion.

Shipping an exe file essentially keeps your source code protected.

yes, we are here to help answering the question, masjiade just pointed out that the information you gave was incorrect.

even so, the question had already been answered, and both answers you gave:
1. create a Jar file
2. use a native program to create an exe
have already been suggested as option, so the only new thing you contributed was another name of a native program, and the error which I quoted you on.

no need to act like an insulted child if someone points that out, since, as you say, we are here to answer these questions and to make sure the original starter of the thread knows what answers contain errors, because, as you put it, we do have our knowledge, and we can filter out the errors, but the starter can't, or he/she wouldn't had to start this thread.

Okay mistake agreed and apologies to the one's hurt.
Thanks for correcting me.

I had a customer once who wanted .exe files instead of .jar files *sigh* guess how happy he was when he found out his program didn't work so well in Linux

??? You can run java on linux. Thats the whole entire point of java, is that its Write Once Run Anywhere. A java app should run exactly the same on linux, unix, osx, cellphones, windows.

Just install the JRE on linux and off you go.

"Shipping an exe file essentially keeps your source code protected".

There is always the possibility of disassembly.

Just make a .jre

??? You can run java on linux. Thats the whole entire point of java, is that its Write Once Run Anywhere. A java app should run exactly the same on linux, unix, osx, cellphones, windows.

I was talking about the windows exe file

??? You can run java on linux. Thats the whole entire point of java, is that its Write Once Run Anywhere. A java app should run exactly the same on linux, unix, osx, cellphones, windows.

Completely agree with you, but I guess Stultuske is mentioning the .exe files over here.

One risk that this procedure runs is that you are basically shipping all your class files which can be potentially decompiled and your source code be exposed to other parties. So if you have the concern of keeping your source code closed you can use the second method mentioned here.
The other method is to use some kind of Java-to-EXE converter software which would take all the class files and optionally the manifest file as input and produce an EXE file as an output. Some of them take theexecutable JAR as input. Shipping an exe file essentially keeps your source code protected.

I agree with you when you say that class files shipped as part of your application can be very *easily* decompiled without any kind of special; all you need is a class file decompiler which are pretty easy to get by. On the other hand, decompiling/reverse engineering platform dependent executables and libraries [static and dynamic] is no easy feat and definitely can't be achieved by a casual script kiddie or a curious programmer; it requires much more expertise.

To avoid the ease of decompiling class files, you can use free softwares like ProGuard which shrinks, optimizes and obfuscates the class files.

Come to think of it logically, it is very much an assumed scenario that developing commercial application in Java and distributing them always has the possibility of the application being decompiled. Such applications rely on restrictive licenses stating that any part of the application is a proprietary entity. Examples include IBM Application Servers like Websphere.

On the other hand, decompiling/reverse engineering platform dependent executables and libraries [static and dynamic] is no easy feat and definitely can't be achieved by a casual script kiddie or a curious programmer; it requires much more expertise.

yes thats exactly what I was trying to put through, but I incorrectly qouted myself which obviously did not go down well with some of the members. No issues and I admitted it.
Thanks.

So far the only applications I've found still require that the computer in use has Java installed.

I've only been successful with "exe4j"
Everything else is just too confusing to use especially since they are all trial versions.

Did you read this yet? Convert Java to EXE - Why, When, When Not and How

PS: If you so "hot" to get your application in EXE format, why don't you pay for the software. Then you will not deal with trial version and people that spent their time to create these converters get credit where due..

So far the only applications I've found still require that the computer in use has Java installed.

The one I have already pointed out, JexePack, does not require java to be installed, it does install JRE automatically when the target machine does not have it installed and you have told to do it that way.
Also to repeat what I have mentioned you would have to purchase a license for this product.

write a simple c program in visual studio.

#include <stdlib.h>
#include <process.h>
void main()
{
system("java class_name");
}

Place the exe file and class file in same directory if you are following above code.

If all experts are agree then there is a problem.

-- Unknown.
Great !!! I appreciate your time.

class HelloWorldApp {
public static void main(String[] args) {

System.out.println("Hallo World");

}
}

commented: And what was your point ? -2

Some people are good programmers while being even greater at pointing out other's flaws and weaknesses. If you can't stick to the topic then why even post at all?

The issue at hand is deployment, not being concerned with reverse engineering. Who really cares if someone decompiles the code you gathered through researching other people's code and all the copy/paste work done to complete the project? So you grabbed a line or two from somewhere, even if from memory you typed it. That's how everyone learned in the first place. As far as I'm concerned, everything any of us will ever write with Java has already been written on the sun.java.com site and is simply not in the same order someone else has taken the time to place it in, as you look upon the manual pages for Java.

The issue is deployment. Some people do not want to force their clients to install a JRE on each system they wish to execute the compiled source files. Ease of use is the issue not being concerned with decompiling and not being concerned with correcting each other's posts time and time again.

No one reading this is innocent of producing something unique when you consider that it is all just letters and numbers and symbols rearranged. Everyone programs on an operating system they didn't write. Everyone programs using a language they didn't invent. Everyone uses a keyboard, monitor and CPU they had no invovlement in creating. What is the point of this conversation other than to flex your brain at each other then?

Converting .class into .exe is, and will always be, to make things easier. Not everyone is concerned with their program being ported from a PC to a cellular phone. Often at times, the client will be one person who knows nothing about a PC let alone how to create a folder (or a directory in a shell) and drag and drop (or copy/move) files from one location to another.

If someone wants to decompile something and learn how to use the language I would much prefer that than the same person walking around in public abusing alcohol or raping women. We shouldn't be devoid of allowing others to learn something through us. No one here learned anything on their own nor did they write the books they read to learn it.

For seemingly intelligent programmers to sit around bashing each other, as they dodge the issue, only proves that most of you did more stealing than you did creating your own logic anyways.

commented: A lot of useless blather that still doesn't answer the original question. -3

What got into you? Not that most of that information is not both misled and misleading. In any case, closing this zombie.

you can convert .class file to .exe file using javalauncher 3.2

Sandep: you can also read dates. this thread is 5 years old, it's no use to reply on it.
besides: if you really want a .exe, Java is not the right language to work with

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.