[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status of Free Java Environment?

Bernd Kreimeier <bk@lokigames.com> writes:

> Question: will it be possible to mix JNI and CNI operations, per
> binary, or even interleaved in source?

The same executable has to be able to mix JNI and CNI, as Gcj will
continue to use CNI to call the core library methods.  I think
you will at the very least be able to specify on a per-class
basis that its native methods are JNI rather than CNI.  I visualize
a command or option to say "here is a set of classes [.java or .class]
and here is a library of native method [shared .so/.dll or static .a]
- generate the necessary glue code between the two.

> I dimly remember suggestions
> that JNI could actually be implemented on top of CNI in Gcj.

Yes. The problem is *invoking* a native method.  Somebody
(the compiler, the linker, or the run-time system) has to be
either told or be able to figure whether a given method is JNI
or CNI.  While JNI as well as System.loadLibrary assume dynamic
linking, Gcj has to be able to support both static and dynamic
linking.  With static linking, you have to resolve all symbols
at link-time.

> 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.

I think that is the model we would like.

> OK. That would imply mixing CNI and JNI is not possible (or requires
> lowest common denominator)?

No.  I'm saying that in certain application you don't want the
compiler to generate reflective data structures, because it takes up
space or might preclude some optimizations.  JNI requires the
reflective data structures;  CNI does not.  Your implication
does not follow.  What does follow is that "embedded Gcj" should
not require any classes that depend on JNI.  (One goal of Gcj is
that you should be able to configure different kinds of implementations
depending on your needs.)
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Reply to: