Using gcj, can we construct a fully compatible Java Platform?

Wed Nov 27 09:40:00 GMT 2002

>>>>> ">" == hope2see <hope2see@chol.com> writes:

>> What I want to know is, what is the loss caused by using AOT,
>> especially by using gcj. I guess there could be some 'cost' to use
>> AOT technolgy.

In practice the AOT technology isn't the problem.
But first the theory. In theory, if you want maximum performance from
AOT-compiled code, then you have to forgo java binary compatibility.
That's a cost. Also there are some optimizations JITs can do that it
is hard for an AOT compiler to do, and conversely -- so this may be a
cost or a benefit depending on your application.
>> FAQ says "GCJ supports all Java language constructs as per the Java
>> language Specification". and then, does it support JVM spec also?
>> (except strictfp)

Yes.
We don't support strictfp right now, and I think volatile may not work
properly either.
There are some missing features (e.g., you'll never see a stack
overflow exception with gcj) and of course bugs.
>> If one use pre-compiled library by gcj, still all the java features
>> (such as dynamic loading/lniking) is ensured? In other words, when
>> one use gij (for execute app classfile) and libgcj (all library
>> already precompiled by gcj), it can work exactly same as JVM?

Yes.
>> In short, Using gcj tech, can we construct a fully compatible,
>> completly functioning Java platform which use precompiled library?

Nope :-(. The library isn't complete. This could be a major problem
for you, depending on what parts of the library you use. We really
have a lot of code here, just not everything. The biggest missing
piece is Swing.
Also there are known bugs. For instance, some security features are
missing.
Tom