13

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!

4

8 回答 8

6

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.

于 2008-09-15T17:52:12.340 回答
4

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.

于 2008-09-15T17:47:03.460 回答
3

Excelsior JET is the definitive answer

于 2010-09-18T05:20:12.547 回答
2

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.

于 2008-09-15T19:03:21.140 回答
0

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.

于 2010-09-17T10:27:34.680 回答
0

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).

于 2010-09-17T10:51:49.397 回答
-1

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.

于 2008-09-15T17:47:11.073 回答
-1

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.

于 2008-09-16T14:28:37.670 回答