Jochen wrote:
> I think we should only use JNI in classpath. We don't need another
> abstraction layer, since JNI is abstract enough.
One of the goals of the Classpath project is to remain VM-neutral.
Using JNI supports this goal.
Libgcj, on the other hand, was written solely in support of the gcj
execution environment. Using CNI is important for performance
reasons.
There are two obvious ways in which we can work:
1. Remain separate, but share code. We both need big chunks of code
to be written. With this arrangement, the code only needs to be
written once (well, the java parts at least).
2. Merge the projects into a single source base in support of all of
our combined goals.
[1] is certainly easy.
[2] is also possible. It will require developing a new build system
in which we can specify JNI or CNI bindings. In libgcj, we currently
put CNI code in the directory with the java source. It's easy to
imagine creating cni and jni subdirectories for each package and
maintain that code separately. It's a little more complicated than
this - but that's the general idea.
Deciding which way to go is important, but not as important as simply
agreeing to work together. The first step towards working together is
for Cygnus to assign all of its libgcj code to the FSF, and for us
both to adopt the GPL+exception license.
AG
--
Anthony Green Cygnus Solutions
Sunnyvale, California
