Is GCJ (GNU Compiler for Java) a viable tool for publishing a webapp?

Question

Is it really viable to use GCJ to publish server-side applications? Webapps?

My boss is convinced that compiling our (my) webapp into a binary executable is a brilliant idea. (Then again, he likes nice, small simple things with blinky lights that he can understand.) He instinctively sees no issues with this, while I only see an endless series of problems and degradations. Once I start talking to him about the complexity of our platform, and more in depth specifics of byte code, JVMs, libraries, differences between operating systems, processor architectures, etc...well...his eyes glaze over, he smiles and he has made it clear he thinks I'm being childishly resistive.

Why does he want a single magic executable? He sees a couple of "benefits":

• If it is a binary executable, then it is hard to reverse engineer and circumvent any licensing. Management lives in constant fear that this is happening, even though we sell into larger corporates who generally do not do cheat with server software.
• There is that vision of downloading this magic executable, running it, and everything works. (No more sending me out to do customer installations, which is not that frequent.)

So, I've done my obligatory 20 minutes of googling, and now I am here.

A bit of background on my application:

What it is made from:

• Java 6 (Sun's JVM)
• AspectJ 1.6
• Tomcat 6
• Hibernate 3
• Spring 2
• another two dozen supporting jar files

What it does

• A streaming media CMS
• Performance sensitive
• Deployed on Linux, Solaris, Windows (and developed on a Mac)

As you can probably gather, I'm highly skeptical of this "compiling Java to native code" thing. It sound like where Mono (VB on Linux) was back in 2000. But am I being overly pessimistic? Is it viable? Should I actually spend the time (days if not weeks) to try this out?

There is one other similar thread (Java Compiler Options to produce .exe files) but it is a bit too simple, the links dated, and not really geared towards a server-side question.

Your informed opinions will be highly cherished, my dear SOpedians! TIA!

Kamat

Answer 1

FWIW: I have never had good luck with GCJ, I have had a lot of problems using it and have had some obscure issues pop up that took forever to diagnose to GCJ rather than me (I am always very very reluctant to blame things on external libraries). I will openly admit this happened several years ago and I have never wanted to go near GCJ again. To give that more substance this was while I was in school and was working on a mostly trivial program so on an "enterprise level" I have had a healthy fear of GCJ.

Addy

Hmm...so GCJ is definitely looking scary. – Kamat

I can only echo Ryan's statements, but with the added info that I've had gcj creep in and break things consistently on a monthly basis over the pasts 3-5 years. (it has a habit of being re-enabled by some debian packages during upgrades.) – Flowery

Answer 2

I don't know about GCJ, but my company uses Excelsior JET with success. We haven't done it with a webapp (yet) but it should be able to handle anything that the Sun JRE can. In fact JET is a Sun-certified Java implementation.

Cloudscape

There is a discount program for very small companies, and public non-commercial projects may qualify for a free license. – Neuman

Answer 3

Excelsior JET is the definitive answer

Mesocarp

Answer 4

Having one executable has a few downsides:

• You can't patch it as easy (i.e. replace one class file)
• I don't think it can be called a webapp -- I assume it won't run in Tomcat.
• It is non-standard so that increases your maintenance costs.
• It is non-standard so tool support is reduced.

If he wants something simple maybe a war or ear would be better. I can't see any benefit to doing this -- I would think this might be beneficial it it was a standalone application that you distributed so that people can just double-click on it.

Lubalubba

About the webapp: that is the code I have personally written, but we are in control of the entire platform and even set special server.xml values. It is demanding enough to warrant a dedicated server. If we compiled to native, tomcat would have to be included I guess. Thanks for the input, though! – Kamat

Answer 5

I've only used GCJ very briefly, and quickly moved to Sun's JDK. The main problems I saw was that GCJ seems to always lag a little behind the latest version of Sun's JDK and that there were weird mysterious bugs caused by subtle differences with Sun's JDK. In version 1.5 (which is supposd to be compatible with Sun's v1.5), I had problems compiling using generics, and finally gave up and moved to Sun's JDK.

I must say, any difference in performance was negligible (for my purposes, YMMV) and really the solution for installation issues is to create an installer for your app. Reverse engineering a binary isn't really all that harder than reverse engineering bytecode. Use an obfuscator if it is that important.

Overall, I think the compatibility problems involved in using GCJ greatly outweighs any gains (which I think questionable at best) you might possible derive from it. Try compiling parts of your app in gcj and see how it goes though. If it works out fine, otherwise you get something solid to pitch to your boss.

Elfie

Answer 6

I'll play devils advocate a bit, though I know little about GCJ.

Compiling to native code may give your application a performance boost and use less memory, so if it can be made to work, there are advantages for the business in terms of competition.

Being able to support an application better is also a good for business.

So perhaps it is worth investigating baring in mind that nothing can lose a customer faster than an application that doesn't work.

You need proper project time to try this out and a customer, that knows what they are getting into, that is willing to give it whirl (harder to find).

Hazlip

I don't believe the argument, that a native compiling would give a performance boost. Long running applications usually profit from a JIT compiler way more than any static compiler can achieve. – Periscope

Answer 7

I don't think that a large application like yours will compile to machine code. Remember that java is not only java syntax (might compile to machine code) but also a virtual machine which is more like an application / process environment. I would suggest making an uberjar or like that instead.

Sonnier

Yes, I am aware of the JVM issue. Hence way I listed the versions and even the AspectJ part. :p Even tomcat would have to be compiled in! – Kamat

The people that developed GCJ are certainly aware that Java is more than just syntax! – Trigonous

-1: Obviously GCJ and other Java-to-native compilers come with runtime libraries that will do the job of the JVM, so this is a non-issue. There will be other problems however, mostly about compatibility... – Jarnagin

Answer 8

Perhaps your boss just needs a demo as to how easy it is to distribute and deploy a war file for your customers on their own app servers. Every file is "binary", so you might be too-literal in thinking he means an executable on the command-line.

Cerebrospinal

Actually, it is not that easy to deploy. We need to do tweaks to the server.xml file. And we deploy to such a wide variety of environments and they all have there favorite OS, DBMS, backup strategy, etc. that "just drop in the war" doesn't work. I should be more clear on why he wants this, though – Kamat

and he does know the difference between machine code and byte code. :P (He is a Flash coder by trade.) And I'm being a bit loose with the term 'binary' above, I guess. Executable – Kamat