NewInstance

Native compilation of Java code offers some advantages over distributing .jar files:

• it cannot be easily decompiled/reversed/hacked
• it doesn't require a JVM on the user's computer
• it doesn't require a startup shell script
• performances: some people believes that native code run faster; I'm a little bit skeptical about this point

On the other side, you loose on

• cross platform portability
• reusability: you can't reuse the native artifact as library as you can do with jar files
• debugging, I think should be much harder not having debugging informations required by java debugging tools
• performances:there are limitations on what you can natively compile, some runtime optimizations made by the jvm cannot be done on code statically compiled

I made a little shell script that was natively compiling a self contained little application packaged in a jar:

#! /bin/sh
gcj -o myapp-executable-file-name --main=it.newinstance.myApp.Main /home/luigi/workspace/myApp/target/myApp-0.6-SNAPSHOT.jar
strip myapp-executable-file-name
upx-nrv -9 -v myapp-executable-file-name

The first command uses gcj (Ahead-of-time compiler for the Java language) to natively compile my jar. The second one strips (Discard symbols from object files) the executable to remove all unneeded debugging informations making the executable smaller. The last command compresses the executable using upx (The Ultimate Packer for eXecutables) reducing a lot the file size: the output of gcj is usually much bigger than the original jar.

In my case, the "closed sources" motivation was pushing me to adopt the native compilation. I know, that's the "dark side"... but sometime the sharing and collaboration philosophy turns against yourself. Some time ago I was using a proprietary build tool which was quite frustrating, so I wrote some little utilities to automate dev tasks, like configuring Eclipse for working on the custom project layout. I was pushing a lot to adopt a standard build system like maven (which also provides plugins to generate IDE configuration files) but, the old men on the project are always conservative ("it worked since now, so... go on") and always the most powerful in taking decisions. Then, I wanted to have the ability of quickly startup my environment, to demonstrate the benefit of good tools and standard adoption, and -first of all- make my job easier. And, of course, this was made one my free time, because nobody wants you to take time to solve problems if formally there is no problems.
But at the same time I didn't want to give sources allowing the supporters of the proprietary build tool to evolve my code and give them more facilities to keep on the same -wrong- direction. I succeeded in creating the tools to ease my job, but I failed anyway to convince others to switch to a standard build system. As usual.
Homeopathic cure against closed source; it didn't work, also on IT industry.