How practical is the GCC native Java compiler as a platform for typical open source Java projects?

Question

EDIT

The original reasoning for this question was a pretty serious case of bad timing, and has therefore hidden away in the editing history. In short, fop 1.0 is imminent, so the motivation is largely gone. Besides, the real motivation was mostly frustration anyway.

Nevertheless, there is a reasonable question here - how practical is the GCC native Java compiler GCJ for building real-world open-source Java projects such as FOP? How hard is it likely to be, and what kinds of problems are likely to occur?

For example, I now understand that gcj implements the JDK 1.2 language and is "largely compatible" with the JDK 1.2 libraries - a long way behind Java 6/1.6. Also, libgcj is missing a lot of libraries, particularly GUI related. AWT is missing which, in the case of FOP, means the GUI viewer is a problem. Though to be honest, what's wrong with generating a .ps or .pdf or whatever and viewing that?

Answer 1

The Fedora Project has used it to compile quite a few libraries and apps for a while now. You may want to look towards their efforts/successes.

Answer 2

I'm very much in the camp that still doesn't understand how Java 1.5 and Java 1.6 can be more recent than Java 2 (or are they variants of Java 2?).

Blame Sun for this inconsistency.

There are two version numbering systems. The original JVM versioning system goes 1.0, 1.1, 1.2.x, 1.3.x, 1.4.x, 1.5, 1.6. The "marketing driven" number system (which Sun uses in their published material) goes Java 2, Java 2 1.3.x, Java 2 1.4.x, Java 5.0, Java 6. So the numbers "1.2" and "Java 2" mean the same thing, "1.3.x" and "Java 2 1.3.x" mean the same thing, and so on.

It happened because the Sun business folks decided that they had to have a Java 2.0, because Java 1.2 looked (to IT journalists, etc) like just a minor release. Of course, this contradicted the established meaning of the major release number which was that it would only change for a release of Java that majorly broke backwards compatibility.

The end result is a confusing dual version numbering, that only sense if you realize that there are two version numbers for the later Java releases. (And the SE/EE/ME qualification ... in its various manifestations ... just adds to the confusion.) Just learn to live with it.

(But hey, if you think this is crazy, look at Microsoft's numbering of Windows releases!)

Answer 3

The issues you might find are mostly related to non-implemented APIs in GCJ, or buggy library implementations. There are also some language features that are not well supported such as reflection.
Why don't you just use Java ?

Answer 4

In a situation where you are trying to use some project that hasn't released for a long time, it is worth looking at the project mailing lists.

Here's an archive for the "fop-dev" mailing list. First, note that the mailing list is active. Lots of postings. Second, if you look at the mails for July 2010, you will see that they have voted to accept the FOP 1.0 release branch. I'm not exactly sure what this means, but I suspect it means that 1.0 is going to be released really soon.

On your general question as to whether to use the GCC native compiler, there is no particular reason not to. But there is also no particular need to do so, and no particular reason to suspect that it would help. I personally prefer to use Sun's JVMs. And it sounds like you might be making life difficult for yourself by trying to get rid of runtime dependencies on a Sun installation.

EDIT

I'm not convinced that the "dependency hell" is that bad. On the one hand, you (as the primary developer) should be able to figure out certain combinations of versions of the components that work. Then you say "these are the versions that we recommend / support". If people want to use different combinations that is their responsibility.

On the other hand, if you use Maven as your build framework, then the dependencies are explicitly declared in the project POM files. If you make sure you publish to a public repository, and that your published artifacts only depend on properly released / published 3rd-party artifacts, then your customers should not have any difficulty either building your software directly, or downloading via the Maven repositories. And if they want to tinker with the dependencies, they can do that.

EDIT 2

Using GCJ as a way to prevent users from screwing up the dependencies is (IMO) a bad idea. By using GCJ to hard-wiring the dependencies into the binary distribution you limit the user's ability to "tinker". And with FOP-based applications, the ability to tinker seems to be rather important.

(And the fact that GCJ apparently causes FOP to break is yet another pragmatic reason to just use a regular Sun Java.)

Answer 5

See this bug report. It's 4 years old, but it's tagged as fop 1.0dev, so I guess it's still relevant. Looks like you won't be able to compile it with gcj without black magic.

Answer 6

As this appears to be a "I need a prepackaged version of FOP and I essentially never want to hear a bug report" as opposed to "We need FOP as part of another product which will have developer attention for quite long and it is essential that this works properly", I will strongly advise you to go the mainstream way and create a traditional bytecode based package which requires the Sun JVM to run.

You will most likely find the "executable jar" concept interesting as it allows you to boil down the startup script to "java -jar .../myfop.jar". The Eclipse "Export" function names this as a "runnable jar".

---

EDIT: After reading the various comments, I understand that what you actually want is a DocBook authoring environment. I believe the shortest amount of developer time spent to get there, would be writing the glue needed for the XML tools in Eclipse to talk to FOP, i.e. an Eclipse plugin.