Java: Excelsior Jet

For the past few weeks I have indulged myself in the wonders of Java programming. For the longest time I had given in to the hype perpetrated by the C/C++ evangelicals, falling victim to misdirection given on the multitude of programming forums. Well, not completely, maybe half-heartedly. The truth is, the more and more I work with Java, the more I find myself preferring it to C’s forced acceptance of low-level details that, when solving an issue in the problem domain not directly related to tight memory constraints or direct hardware access, I really don’t have the time nor desire to really address. This is where Java comes into play. I can look past Java’s heavily Object Oriented bias due to the large native libraries that do so many great things like XML manipulation and Zip file support and the overwhelming number of third libraries such as the Apache and Eclipse libraries. In fact, just this weekend I was incredibly impressed by the ease of creating code to unzip files by using the java.util.zip libraries.

Despite all that praise, I do have one major gripe, which is perhaps a showstopper for my using Java as my day-to-day language. While I understand that one of the major advantages of Java is the ability to compile once and run anywhere, I find it annoying that I cannot compile to my native platform and take the JVM middleman out of the equation. Seriously, why is it ten years later, if not more, and Java still does not have native compilation for a platform of choice. That is the key word after all, choice. While anything below a scripting language needs compilation, Sun is really missing an excellent opportunity. Others have tried such attempts, such as Microsoft’s Java and the GNU Java compiler, their compatibility and support leaves much to be desired. Hell, Microsoft’s piss poor implementation is far behind the Java compatibility curve that their inclusion of it in their developer suite is an insult to the other languages.

Fortunately, there is one product that seems to understand that despite Suns philosophical beliefs, they are not powerful enough to force a paradigm shift away from the .Exe expectancy in Windows users (I omit *nix from these expected .exe paradigms since most a good majority of the users of these platforms are used to using PERL and are aware that scripts can be invoked from the command line via an interpreter call in addition to the first line indicating the interpreter to use). Unfortunately, native compilation comes at a large price, but the product to get the job done is Excelsior’s Jet.

As far as getting the compilation done, Jet provides a very easy to use wizard that walks you through, step by step, how to compile. There are a few caveats. First, the code must already be compiled into a .jar file. Second, you need to know the class path for running the program. For example, to run the CLI example I had previously written about, I would normally run the following command:

java -cp C:\birt_runtime\birt-runtime-2_1_0\ReportEngine\lib\commons-cli-1.0.jar;C:\temp\clitest.jar; clitest.CliTest

Once I input this into the classpath entry and hit the parse button, the program will ask a few more questions, and then parse a native x86 exe file. The only issue is the inclusion of the Jet Runtime in any programs that would be distributed.

That’s the good news, now comes the bad news. The program is expensive. Not as expensive as other compilers, however it is a little pricey for someone who, like me, is a hobbyist, not a professional. I can live with creating batch files to run my Java apps for the cost; however, if I were a professional java developer targeting a specific platform (Windows, Linux, etc) this would be a highly considered addition to my toolkit.