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/