FreeSwing, EvolutionAlgorythms

[Per Bothner]

Tom Tromey <tromey@cygnus.com> writes:
> Also, for us, we'd rather see native code using CNI and not JNI.  This
> probably reduces the potential for collaboration.

I suspect Tom won't disgaree with any of this, but I will expand

(1) It is a goal that Gcj should support JNI as well as CNI. Doing so
is not in principle difficult, especially dealing with JNI-using
libraries that are known at link-time (since you can just generate
CNI wrapper functions that call the corresponding JI methods).
However, there is still a for bit of tedious work needed for JNI.

(2) We do prefer CNI, as it is more efficient, easier to write, and
(at least potentially) easier to debug.

(3) You could in primciple write C++ code that implement both a CNI
and JNI interface, using the magic of pre-processing.  The question is
whether we can do it in a way such that it would not be simpler and cleaner
to just maintain two copies of the code.  We don't know yet.

(4) In any case, a working JNI version would be very helpful, because
it provides a specifiction/prototype.  The code might have to be
re-written to use CNI instead of JNI, but that should be a much
easier task that writing it from scratch.  (Presumably the translated
version would be a "derived work", so copyright issues are still
important.)
-- 
	--Per Bothner
bothner@pacbell.net  per@bothner.com   http://www.bothner.com/~per/