Artur Biesiadowski ([EMAIL PROTECTED]) wrote:
> One thing is sure - they are very quick to use native code, because it
> is extremly easy with gcj. Classpath tries to stay on java side as long
> as possible - to minimize JNI overhead and make porting easier. Gcj does
> the opposite - everywhere where it is feasible they go for C++ code.
Well, since gcj compiles Java to native anyway, I don't see the benefit
of native code. It might possibly be more efficent, but it is defintely
less portable. Why not write in Java and let gcj figure out the
portability problems for you?
> Next thing is that they do not need javadoc comments - just something
> working. As javadoc is about half of work on class it is a major
> difference (when you will think about some classes like java.sql, lack
> of javadoc can be a real difference in time-to-market :)
As the person who wrote java.sql for Classpath, I can tell you this
is definitely true.
> [...]
> >d) Is there any talk afoot (hmm, mixed metaphor) of GCJ working with
> > Japhar? [...]
> I don't know, but I doubt it. You do not design high performance static
> compiler to later bundle it with slowest vm available. Japhar has bad
> design, is slow, has nothing in common with C++ layout of objects... You
> would have to rewrite all of it except maybe interpreter loop and few of
> class loading routines. But writing simple interpreter and class loader
> is few days for cygnus folk, and they will get something working with
> their runtime data.
gcj is a static compiler, not a JIT as you noted. In fairness, Japhar
aims for standards compliance first. Speed is only a secondary
concern. Right now Japhar supports Java 1.2 and the JVM debugging and
profiling interfaces. I imagine you will see more work on speed as
it develops.
--
Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
