[gsmethells]

As far as packaging and deployment of a native executable goes, I thought it odd to not mention Excelsior JET (http://www.excelsiorjet.com) as I believe that's the only Java compiler that can handle all of the JDK (gcj isn't there yet).

[pjmlp]

gcj is dead since 2009.

The only alternatives, besides Excelsior, is the new RoboVM, Websphere Realtime JVM, Aicas, Aonix among a few other ones.

And if Graal eventually replaces Hotspot on the reference JVM, it might be that Truffle comes along as well.

[pron]

Native executables are not always what you want. For example, they don't get security patches.

[Pacabel]

That's total nonsense. Binaries (or shared libraries they depend on) can be and are updated, on all sorts of systems. In many cases it's as simple as overwriting the existing binary with the updated version.

Heck, the runtimes you're advocating are generally installed as binaries. If they can get updated, then so can any other binary.

And if a user doesn't bother to update a given application's binary when a critical flaw of some sort is found, then there's a very good chance they wouldn't bother to update any runtimes that are installed, either. This is true even when some sort of update notification and installation process is offered. The end result is the same in either case: the update is not applied.

Runtimes shouldn't be portrayed as any better in this case, when they're generally no different than any other binary.

[pron]

Anything can be done in many different ways. It all comes down to convenience. When a library is found to have a security flaw, you can either upgrade all binaries, or just upgrade one runtime. You could say that your OS is just a binary, too, and that's true. But it's a binary that adds a lot of convenience. A lot of people think runtimes add convenience, too. You obviously don't agree, and that's fine: use whatever works best for you.

http://xkcd.com/378/