Aaron M. Renn wrote:
> Jochen Hoenicke ([EMAIL PROTECTED]) wrote:
> > I have invented an ad hoc abstract language and have transformed the
> > natInflate.cc from libgcj (java.util.zip.Inflate). I have used the
> > prefix JCL_ for the pseudo methods. I haven't implemented everything,
> > yet, only what I needed for Inflater. See:
>
> Did anyone else take a look at this? Personally, I don't like this
> approach. But the alternatives aren't great. Here's what we've got:
>
> 1. Metalanguage/macro approach. See Jochen's code at:
> http://www.Informatik.Uni-Oldenburg.DE/~delwi/classpath/JCL/Inflater.jcl
>
> 2. #ifdef's
>
> 3. Separate implementations of JNI and CNI.
>
> 4. Write a JNI <-> CNI adapter layer
>
> 5. Make gjc support JNI and stick with that approach.
Way I see it, the JNI v. CNI represents two different approaches to the same
problem (allowing Java classes to interact with native code). The first
approach (JNI) stresses cross-platform compatibility (here I am referring
not only to different operating systems and architectures, but also
different VM's on the same arch/OS) at the expense of performance. The
second approach (CNI) stresses performance (as well as ease of maintenance)
at the expense of cross-platform compatibility.
How difficult would it be to implement both approaches (perhaps as #ifdef
macros or pluggable header files), and then provide a build-time option to
use one or the other?
Perhaps something like:
./configure --with-cni
Ian
--
"And it ought to be remembered that there is nothing more difficult to take
in hand, more perilous to conduct, or more uncertain in its success, than
to take the lead in the introduction of a new order of things."
-- Nicollo Machiavelli, 'The Prince'
