Develop Reference

Java to EXE good or bad idea?

I have been wondering for a long time about converting Java projects to EXE.
The advantages relies in the faster deployment on Windows where the user simply double clicks the EXE and the application is launched where is with Java, he has to run certain commands.
But EXE is really not what the Java was intended for which is portability.
So what do you think, Java to EXE good or bad idea?
I found some interesting article here.
Update
Wow, so may contradicting views so far. I would like you guys to add the pros and cons of the JAVA to EXE.

Since my expertise is with Java Web Start, which is for launching desktop apps. with a GUI, please consider my advice to be targeted mostly at those types of apps.
Other people have commented on the OS specific nature of an EXE. I always have to wonder why people choose Java to develop Windows specific desktop apps., since the Visual Studio software for Windows would probably make both GUI development (no x-plat Java layouts to bend your head around) and deployment (just guessing it can produce an EXE) easier.
OTOH only you can say what is the best development tool/language for this use-case.
As to the potential disadvantages of creating an EXE, I note at the JavaFAQ on EXEs.
There are a number of good reasons not to package your application in an executable. Daniel Sjöblom notes:
It will probably not be any faster. Modern virtual machines don't interpret bytecodes, they actually employ a JIT compiler to produce native, compiled code. Check Sun's site for further information on JIT compilers.
Static compilation increases the size of your application multifold, since all of the libraries you are using need to be linked into the application.
You lose 'free' upgrades to your program. Anytime your user downloads a new faster virtual machine, your app gets a speed boost. If you are using an exe, you will not get this benefit.
Jon A. Cruz details some of the extra steps in the development process required to create an exe. He points out that developers making native exe's need to:
Validate the latest versions of the compilation product from the vendor. If critical bugs are found, it can't be used to build a shipping product until those are addressed. Work that needs to be done each time a revision comes out from the vendor.
Submit the software through a QA cycle. Once engineering thinks things are done, they need to be verified. So every shipping version and update of a product needs to go through complete testing cycles.
Further, since native compilation is per target platform, the QA cycle needs to be done completely for each target platform, which multiplies effort required.
Shelf space. Maybe not a big deal nowadays, but could be.
Then one needs to get all customers to upgrade to the proper version. Either have free updates (in which case the business needs to absorb the cost of producing updates) or alternatively needs to handle clients not all updating.
Jon notes futher: When you ship standard Java bytecodes, VM problems are the responsibility of the platform or VM vendor. However, when you ship compiled binaries, they become your responsibility (even if they're actually bugs in the vendor's compilation product).
...
Of course, my first choice for deploying Java rich client apps. is using Java Web Start. Putting some of the benefits/features of web-start in point form:
JWS provides many appealing features including, but not limited to:
splash screens
desktop integration
file associations
automatic update (including lazy downloads and programmatic control of updates)
partitioning of natives & other resource downloads by platform, architecture or Java version,
configuration of run-time environment (minimum J2SE version, run-time options, RAM etc.)
easy management of common resources using extensions
..
I decided to highlight auto-update since with the gradual shift from apps. delivered on disk to apps. delivered over a network, auto-update is becoming more common. JWS still provides the best update experience (very configurable, mostly transparent to the user) I've seen.
And of course, JWS works on OS' for desktop PCs for which Java is available.
Update
..does Java web apps require internet connection?
(Note that name is 'Java Web Start'.)
Sure it does. At least for the initial installation. Update checks can be specified to continue to launch the previously installed version of the app. if the user is not currently connected.
But then, (in my estimation) there are more machines (such as Netbooks) with no CD/DVD drive, than there are without internet connections. If you want to sell to the larger market, look to the network to deliver the app.

It depends on your needs. We had written a little barcode client scanner app here for our customer. They run it on two Windows-PCs. They are happy having their well-known exe-files. We coded it in Java and created an EXE-file for them.
Both parties are happy with it - so why not doing it?
When there are good reasons for it and nothing against it except dogmatism then it is ok in my opinion.

I am the author of the article you linked to - glad you've found it interesting!
As my article states, and as others have already pointed out in their answers, there are multiple ways to simplify deployment of Java apps - JNLP, EXE wrappers, installers bundling a private JRE, and so on. But true native compilation is the only option that also provides protection against Java decompilers - you simply do not ship the bytecodes.
Of course, that does not make reverse engineering of and tampering with your code impossible, just much more costly in terms of required skillset and time.
As far as application performance is concerned, native compilation can make a big difference if you target embedded systems. This also applies to memory and disk footprint, albeit to a smaller extent. On the desktop you would typically get better startup, but in most other scenarios and aspects the results would depend on your app.

If it has a good reason why not? Even Eclipse has an EXE on windows and (and platform dependent binaries for linux, mac, etc) Of course you loose portability but if that is not important then go ahead.
UPDATE
The question is what do you want to achieve by creating an exe :
Convenience : users on windows prefer to click on icons, this is especially true for the non geeks. On the other hand non geeks don't care what the link does internally if it starts up an exe or something else. You can have an application icon for non native Java applications too. The alternatives would be
Web start
Creating an installer package,e.g.: http://www.advancedinstaller.com/java.html This can also solve the problem of installing the JRE
Performance : If you compile your Java application into a native solution you may gain a bit on performance but it depends on what technology you use. For example Swing tends to be slow but compiling that to native is rather tricky. If you use SWT instead of Swing that is already using native components therefore no need for further native compilation. On the other hand recent JVMs perform very well and can compile java to native to further improve the performance bottlenecks. This is done silently on the background you dont need to worry about that.
Sum : in some cases it might be the only solution, but if you choose the right technologies there will be many Java based alternative solutions to reach the same goal.

The page behind the link in the question is written by a company that sells products that compile java to native code. I would not base a decision on that alone.
The question also says that the advantage of the exe a better user experience, because the user can just double click to launch the application.
That is possible with executable jar file. In fact, its actually quite easy with standard tools in the java runtime. You just have to add a manifest to a jar file, and specify the class with the main in it. You can also specify other jar files in the classpath relative to the location of the main jar file. You can also specify an image to use as a splash screen as a resource.
e.g.
Class-Path: lib/derby.jar lib/derbytools.jar lib/jcalendar-1.3.2.jar l
ib/joda-time-1.4.jar lib/log4j-1.2.14.jar lib/looks-2.2.1.jar lib/swi
ng-layout-1.0.jar
SplashScreen-Image: resources/splash.png
Main-Class: com.you.pkg.app.Main
The basic ant project in Netbeans will do all but the spash-screen for you if you use it. If your some reason you want to do all of that by hand, make sure you understand the format of the manifest file, its a bit finicky.

As Linux, mac., Solaris user I think this is bad idea.
If you want faster deploy on windows, just create installer.

Jar files provide many benefits including:
Compact: The whole application (i.e. all the class files) is stored in one archive file (which can incorporate image and sound files if required).
Ease of use: The application can be run by double-clicking.
Compression: The jar format allows you to compress your files for efficient storage.
Security: You can digitally sign the contents of a jar file. Users who recognise your signature can then optionally grant your software security privileges it wouldn't otherwise have.
I would not convert to exe.
Most Windows applications run from a .exe file (Word, Internet Explorer, FireFox, NetBeans, ...)
Java itself has no support for doing this as the executable file will then be platform dependent (i.e. it won’t run on Macs)
However, there are (free) applications that can do this for you.

Minecraft does it, so it must be a good idea!
All jokes aside, understand that it's not 'conversion' that you are looking for, but using a custom launcher. The article you linked does a nice job of explaining the different approaches and pros/cons of each. As a general idea, it requires the extra work of creating the launcher (and a different version for each different OS architecture), but it gives you a little more control (version checking is a nice feature, also you may update the application jar rather easily, like Minecraft does). Overall it's a good idea if you think it's worth the effort, and the (little) loss in portability.
Edit: the 'Custom Java Launchers And Wrappers' approach is the one that you should use if you don't need the really nifty extra features offered by those below it.

Depends on the user base. If they are tech-related in anyway then giving them a .jar file (which could be run by double click) is a good idea for mobility.
If your users are less techy but you still need it to run on multiple platforms then wrap it as exe for Windows and as .app for Mac.
Important: I would suggest making a script to wrap it into exe, so you run it each time you have a new version.

Compiling multiple Java packages with TextMate

I've recently been converted to TextMate as a diverse and powerful programmer's tool. But it appears to be lacking in Java support. So, I've been trying to mess around with the supplied Java bundle (Compile & Run) but it only contains one line:
javamate_bootstrap.sh
I can't find this file on my machine, but it appears to only work for simple Java classes (ie, classes not contained within a package).
First of all, why is TextMate so useless for Java programming, and secondly (and most importantly) : Does anyone know of a bundle I can use, or have instructions on how to create one for larger scale Java development in TextMate?
Thanks in advance.

First of all, why is TextMate so useless for Java programming
Mostly because there are three free (free as in beer) java IDE's, IntelliJ IDEA, NetBeans and Eclipse that almost all professional java developers use. Any one of them will give you all the functionality you want out of TextMate and much, much more. Given that, there's not much demand for java features in TextMate or BBEdit, or Notepad++, etc. That's not to say people don't use them. They definitely do, but not in a high enough volume to make it worth it to the maintainers to add features to make java development easier.

Practical Java - Development Environments

I've had several classes - university level - on Java.
However, what these classes lack is some practical approach to Java - or, to programming as a whole. Things you can only learn in a business.
However, since I am not allowed to use Java on the workfloor, I don't get to learn this now - even though I would like to.
So I guess what I'm asking for is any number of plain have-to-know Java resources. Things concering, for example, what Ant is and why and how to use it; using revision control systems from your IDE; standard Java libraries you would use often ... Anything that would help with actual software development, really.
As some side information, I've been using Eclipse for about four years now, and I feel at home there.

I have a system that works fairly well for class assignments and for projects as well. Firstly, I create one Eclipse project per class. This way I can re-use classes from previous assignments. You can also customize your classpath by adding another project as a library.
I use the Maven plugin for Eclipse M2Eclipse. Not only does this give you the ability to search for libraries and add them easily but the exec:java plugin is an easy way to execute your code from the command line. It's helpful because when it executes your code, it uses a classpath that includes all linked Maven dependencies. If you aren't using external libraries, you might not need Maven but I've found it to be helpful to learn in preparation for the job market. It's fairly simple to start with plus there are a ton useful plugins for open source projects.
Next, for revision control I recommend Subclipse. You can get a free SVN account with a single login from Unfuddle.com. Link that up to your Eclipse environment and Import your project.

When I want to get a particular class specification, I go to Sun's Java documentation.
Another excellent resource that will certainly give you the reference material (searchable!) to answer any java question would be this torrent containing ~100 ebooks on Java, sorted by directory on various topics (like Ant, Eclipse, or Swing).

How do I mix JVM based languages in a single Netbeans project?

For example, is it possible to have Scala, Java, and Clojure source all compile/build together properly inside the same project? Or, do I have to do them as separate project libraries then used by whatever I pick as the "master" project?
If neither of those, how's everyone else doing it?

Unfortunately, while the Java community seems to be very enthusiastic about polyglot programming, the IDE vendors haven't really kept up. They generally do have plugins for Java, Scala, Clojure, Groovy, Ruby, ECMAScript, Python, C++ projects, but mixing multiple languages in one project is generally not supported.
In Ruby, for example, it is quite common to use Swing as a GUI via JRuby. But if you want to use Matisse, the NetBeans Swing GUI builder you must use a Java project, you cannot use Matisse in a Ruby project. However, if you use a Java project, then you can't have a Ruby main executable, you must have a Java main executable. Also, you don't get Rake support and other things that the Ruby project type supports. (The ugly workaround is to write a Java main executable which creates a JRubyEngine instance by hand, loads the Ruby main executable into it and runs it.)
The Eclipse Scala plugin supports a limited amount of polyglotism, but the hoops that they have to jump through are tremendous. Basically, they use runtime bytecode patching to inject Scala Aspects into the Java Development Tools Eclipse plugin, to get type-driven cross-language refactorings to work. The Groovy plugin does similar things, as does AspectJ (in fact, they originally came up with the idea of using aspect weaving to inject new functionality into JDT). So, all of these plugins allow polyglot programming with themselves and Java. But unfortunately not with each other. (Although several of the maintainers have expressed interest in more closely collaborating.)
In general, I fear that the only solution is new IDEs.

Rather late to answer this question, but the answer is that IntelliJ IDEA does a very fine job on polyglot programming. I recently watched a demo where one of their developers did a mixed-language application in 5 (!) languages.
They manage to do multi-language-aware syntax coloring, refactoring and more. They've obviously sunk some effort into this and are justifiably proud.
I was very happy to note that IDEA is now (partly) open-sourced.

Best way to create a standalone program for windows without having to install pre-requisites?

I've been charged with creating a little GUI launcher app to go on a CD which will offer the user some software and some videos. It's not being aimed at particularly tech-savvy people, so it needs to be quite simple. I guess the real sticking point here is that it will be form based.
I would very much like the launcher to just run from an exe without having to install any .net stuff or have java installed. I know ClickOnce is fairly simple and I will fall back on it if necessary, but I thought it might be worth asking if there are any easy ways to do this.
I mainly program using visual c# these days, but have experience with java and c and I am a relatively quick learner, so feel free to suggest other languages.

The most straightforward way to create a dependency-free executable for Windows is to use ordinary Win32 functions from C (or C++). Alternatively, you could use MFC with C++ because you can link MFC right into your executable to avoid a dependency on MFC DLLs.
There are probably other C/C++ frameworks that can be linked into an executable. However, you probably want to avoid Java and C# or any other .Net language, if you want minimal dependencies.

Depending on the minimum target OS, you could possibly choose VB6, if it doesn't affend you too much, because the VB6 runtime has been included in windows since Windows 2000. However, you need to stick to the included controls to keep things simple.

If you write it in Java you could bundle the JRE on the CD and just have a batch file that uses that bundled JRE to launch the app. This should work, but the JRE is kind of large, so you'd need to make sure you'll have enough space on the CD for it.
.Net might be able to do something similar but I've never looked into it at all.
The simplest thing would probably be to just write a simple native app in C/C++ (or in some other language that compiles to a standalone EXE) and use that.

Just statically link to the C runtime library and any others you might need (like MFC): /MT or /MTd on the command line and Project Properties > C/C++ > Code Generation > Runtime Libraries in Visual Studio.

You can use C++ with wxwidgets for GUI and statically link your application

Now all the windows OS (from win 2003) pre installed with .Net frameworks... so you can go ahead and code in any CLR language...
You are saying ur clienats are not tech ppl, so the chances for uninstalling .net frameworks from their machine is very low..