Wes Biggs wrote:
> a) Is there a good reason to have a totally separate set of .java files
> from those in classpath (given that both are LGPL)? Obviously a lot of
> java.lang, etc., needs to be different based on virtual machine (or lack
> thereof), but not the pure-Java stuff. I know Kaffe has its own
> implementation, and that's based on (theoretically at least) the
> different design tradeoffs to target embedded systems. So a sub-query
> here is whether GCJ's design requirements are fundamentally different
> than Classpath's.
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.
I suppose that gcj and classpath can share some code - like java.beans,
java.sql, but most core packages can be optimized by applying either C++
code, or mix of C++/java but with specific target (gcj/gcc compiler) in
mind. And speed and small footprint is a defnitive aim for gcj - it has
to run on embedded targets (and need speed - in other case what would be
a reason for static compilation).
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 :)
[...]
>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.
Artur
