John Goerzen wrote:
> Also, not sure where it gets [Gcj] class libraries from, but it doesn't
> seem to even fully implement Java 1.1! (No AWT!)
It gets it from libgcj. I'd like to point out that the wording
"[not] even fully implement Java 1.1" overlooks the fact that (a)
you can do a lot of useful stuff without (say) awt, (b) "fully"
implementing Java 1.1 is a major undertaking, and (c) of other free
Java projects, only Kaffe claims to fully implement Java 1.1.
Bernd Kreimeier <[EMAIL PROTECTED]> writes:
> No JNI, actually. Cygnus favors CNI, which makes this an incompatible
> tool for all and any Java code using a native method. Classpath or
> Kaffe AWT is just an example. I have read suggestions that you should
> port from JNI to CNI ("it's really easy"), which IMNSHO is just missing
> the point.
No, I think you're missing the point. (Our fault for not explaining
it well enough.) Gcj has never been opposed to providing JNI: In fact
I started implementing the framework for it, a long time ago, hoping
someone would finish the job. (Now it looks like that will finally
happen.) What we/I have claimed is that (a) JNI is philosophically
inappropriate for Gcj, at least as the primary NI [see below];
(b) that CNI is easier *and* more efficient; (c) hence we
prefer to use CNI for the code *we* write and maintain, such as
libgcj; and (d) we have limited resources, and (until now) other
things have had higher priority.
It is perfectly reasonable for *you* to prefer JNI since it is more
portable; however, that is not that much of an issue for core java.*
libraries. The JNI/CNI issue is not the reason libgcj can't use
Kaffe's or Classpath's libraries; the licensing issue is. If that
were resolved, I don't think it would be very difficult to convert an
JNI-based library to one using CNI.
Another point: JNI requires reflection. In an embedded system you
might want to compile Java code so it does not generate data structures
for run-time reflection, as they take up a good deal of memory. If
you depend on JNI, you don't have that option.
This is something I wrote about CNI vs JNI:
We use CNI because we think it is a better solution, especially
for a Java implementation that is based on the idea that Java is
just another programming language that can be implemented using
standard compilation techniques. Given that, and the idea that
languages implemented using Gcc should be compatible where it
makes sense, it follows that the Java calling convention should be
as similar as practical to that used for other languages,
especially C++, since we can think of Java as a subset of C++.
CNI is just a set of helper functions and conventions built on the
idea that C++ and Java have the *same* calling convention and
object layout; they are binary compatible. (This is a
simplification, but close enough.)
[Note: I no longer work for Cygnus or their Java group, though we
keep in touch.]
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
