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

[Tom Tromey <tromey at redhat dot com>]

>>>>> ">" == 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