Re: Status of Free Java Environment?
Per Bothner wrote:
> 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.
Agreed on all 3. Further, implementing Java2 is a legal minefield.
Actually, I'd trade AWT for JNI any day, but I'm not the typical
Java coder.
> Bernd Kreimeier <bk@lokigames.com> writes:
> > No JNI, actually. Cygnus favors CNI, which makes this an incompatible
>
> 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.)
Way cool.
> What we/I have claimed is that (a) JNI is philosophically
> inappropriate for Gcj, at least as the primary NI [see below];
No objection. Just to clarify: I am not a particular friend of JNI.
Unfortunately, it is a standard, and lots of stuff (including the
free software projects that might complement Gcj) uses it.
> (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.
I can perfectly understand this part ;-). Also, JNI does not have the
slightest notion of C++ bindings (cosmetics aside), and I find it
very unsettling having to glue native C++ OOP and Java OOP through
a C API. Not even to talk about performance.
Question: will it be possible to mix JNI and CNI operations, per
binary, or even interleaved in source? I dimly remember suggestions
that JNI could actually be implemented on top of CNI in Gcj.
> 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.
The conversion process as such is still overhead. The way I see it,
a lot of source will come as JNI, and could be used as is with JNI
support. In case somebody finds the performance gain (or maintenance
ease) worth the porting effort, some or all of the code could be
ported to CNI. You get a migration path that will help acceptance
for CNI. "Difficult" is usually not the only criterion, just plain
typing can be.
> 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.
OK. That would imply mixing CNI and JNI is not possible (or requires
lowest common denominator)?
b.
--
"Problem solving is hunting. It is savage pleasure,
and we are born to it." Thomas Harris, Silence of the Lambs
Reply to: