"Aaron M. Renn" wrote:
> 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?
I agree. And also, it doesn't look like their implementation is any more or
less native-code reliant than classpath.
> > 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.
I think one could argue that all anybody needs is "something working".
Having well documented code also means less reliance on Sun's javadocs, which
sounds like a good thing to me, even though it doesn't help the code work any
better or faster.
> > 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.
It's possible that GCJ could get away without requiring an interpreter if it
can do runtime compilation of bytecode --> native code on a class-at-a-time
basis. I think this would have major performance ramifications in the kind
of apps I mentioned, though, and an interpreter, or an interpreter with a
JIT, would be a useful addition.
BTW Aaron, no problem, I'm interested in hearing what response you get from
Cygnus.
One other thing someone mentioned, as far as licensing is concerned -- libgcj
is under the LIBGCJ License (who woulda thunk), which is a wrapper license to
the LGPL. I don't think this has much to do with some client that the LGPL
was too restrictive for, unless the client is easily fooled. :-) (Anyway, who
goes to Cygnus and asks for proprietary software?)
Wes
