Creating .exe files from .java or maybe it is not the way to go?

Question

As a comp-sci student, I've been making programs mainly in Java and all i have done is make .java files and submit them to instructors to get marks.

I am wondering how to go from .java file into .exe files that i see in my computers.

I looked up on Google and this site, what they say doesn't really make sense because they say the only appropriate way is to create .jar files which requires Java environment installed in others computers and I haven't seen any .jar files in my life.

Also, they say using softwares like launch4j kills the true purpose of Java and might cause errors.

I am confused. Maybe Java is not a language for making .exe files? then what language is? How can I make .exe files and what is the most common way of doing it among the professional programmers?

Note: by the .exe file I don't mean installation files, I mean just the program itself like starcraft2.exe, utorrent.exe, calculator.exe , etc.

Answer 1

Java programs do not generate .exe files, but .jar, because, on compilation, Java code doesn't turn into machine code, but bytecode. The bytecode files are then united inside a .jar file (in a similar manner to .rar and .zip files) and executed through the Java Virtual Machine.

To create a .jar file, you can check out this Java tutorial that Oracle has: http://docs.oracle.com/javase/tutorial/deployment/jar/build.html

If you want to create .exe files through programming, you would want to learn C, C++, Assembly and C#.

Since you already know Java, I would recommend you get into C#, if you want, since both languages are very similar.

Answer 2

Education

The situation in Australia at least, is that most educational institutions run Mac OS X rather than Windows, so a Windows style .exe would not run on those machines. E.G. my brother works in tertiary education, where they push OS X pretty hard. My cousin was recently complaining to me that her son's school required them to pay for a Mac based machine for the students. I explained to her that was mostly because Apple puts a great deal of thought into making their OS and applications so easy to use that the student is able spend more time doing stuff, than trying to figure out how to do stuff (I run Windows because it works out cheaper for me).

What they need

So if your teacher wants to see code, they will need a .java file. If they are happy 'looking at a finished executable' they will probably require either an OS X based DMG or can get by with a Java based Jar.

Distribution

In days gone by, people would distribute applications on a floppy disk or CD, but times change and the advantage has now swung distinctly towards distributing via the internet or a network. There are now more machines that are 'internet ready' than have floppy or CD drives (mostly because of things like Netbook computers).

After initial distribution, there is also 'updates and bug fixes', and again the network trumps the disk.

Java has long had Java Web Start to do internet based distribution and update. JWS of course works on Windows, OS X & *nix - all the platforms for which a Java Runtime is supplied.

Availability of the plug-in

Of course, a Java app. requires the Java plug-in, so to account for that, Sun developed the Deployment Toolkit Script. It is a small script which we put in the web (intranet) page from which the app. is distributed.

The script checks for a suitable minimum version of the plug-in before offering the download button. If the user does not have it, they are guided through the process of downloading and installing it.

Security

As time goes by, OS makers are also cracking down more and more on security. On Windows, there is User Access Control. Sun had long been aware of the dangers, and sought to protect the reputation of Java by forcing Java applets to work within a security sandbox, and if the applet needed to relax the security restrictions to do things like printing or accessing the local file system, the code needed to be digitally signed by the developer, and trusted by the end user when prompted. Sun automatically carried that security over to apps. launched using JWS.

After recent security bugs were uncovered and fixed by Oracle, they decided that even sandboxed code need to be digitally signed, and it won't be long before code needs to be signed by a valid certificate issued by a Certification Authority. These organizations go to efforts to identify the people or institutions to whom they issue certificates, so the prospects for getting 'anonymous code' onto a machine are severely curtailed.

For a developer, it can be a hassle to gain a certificate, and digitally sign code, which might make an .exe seem attractive, but with the Microsoft based User Access Control, it is getting to the stage where most .exe files are also digitally signed.

Conclusion

Stick with the pure Java based route for apps. developed using the Java language. The only real advantage of making a .exe is that an executable is slightly better attuned to the 'look and feel' of Windows. But if you need the 'true Windows' look and feel, it would be better to use a Windows based language (i.e. not Java) to develop it. It would also be easier for two reasons:

1. Java sticks to a set of core functionality that it can support on all OS', so we sometimes need to include native code if we want to go beyond that. E.G. There are no Java based screensavers, and no Java based OS tools.
2. It would be slightly faster to develop the GUI using a Windows based language and IDE, since the programmer could use Drag and Drop to make it. To make a robust cross-platform GUI the Java developer needs to understand and use Java layouts, which can be a steep learning curve, and are not very conducive to being built be Drag and Drop.

Answer 3

.java files are the source files of a Java program. (so, the human readable language) Those needs to be compiled into a language the computer understands (or in the case of Java, what the Java Runtime understands). Those are the .jar files. Jar files aren't really run by Windows itself (which is what .exe files are for) so there isn't really a way to convert a .jar file to a Windows executable file.

"But Minecraft has a .exe launcher!" I hear you say. That's right! But minecraft.exe is just a link to minecraft.jar, located in your Minecraft folder! That's the closest you will get to a "pure" exe file with Java I think.

So, to make a "real" .exe program you need a language that doesn't use a VM and is executed by Windows itself. A few examples are C, C++ or Microsoft's own .NET languages like C# and Visual Basic.

Answer 4

.jar files ("java archive") are basically zipfiles containing a set of Java .class files. They're used as a way to distribute a related group of classes, whether that be a reusable library or an application.

The .class files are produced from your .java files by the Java compiler (javac). They contain object code (executable "bytecode") for an imaginary machine, the Java Virtual Machine (JVM). To execute them, you launch the JVM, telling it where to find the classes (via the classpath) and which class it should look for the main() method in. Launching from a jarfile is essentially a shorthand way of doing that.

It's the JVM's responsiblity to read in the bytecode programs and execute them -- either interpreting them step by step, or compiling them into machine code "just in time" to be executed (you'll hear mention of the JIT compiler, which does the latter). You don't generally have to be aware of that detail, though -- you just hand your classes and/or jarfile to the JVM and let it do what it needs to do.

Yes, this is different from most languages, which generate object code intended to run on a specific processor family and operating system. It has the advantage that Java code, if written well, can run more or less anywhere (assuming there's a JVM and libraries -- the Java Runtime Environment, or JRE -- to execute it). It does impose some complications and limitations, which may be a good or bad thing depending on what you want the program to do and what the person running the program wants to let it do.

In the past, there have been "native" Java compilers which fully compiled the bytecodes to executable code rather than waiting for the JIT compiler to do so. Those could produce real stand-alone .exe programs. But the VM and JIT approach is more flexible, easier to support, and provides surprisingly good performance so the native compilers have pretty much died out again. If you search hard enough you may be able to find one, but it probably isn't worth your effort.