Re: Proposal for CNI/JNI problems

[Stuart Ballard <sballard@netreach.net>]

"Aaron M. Renn" wrote:
> 
> Paul Fisher (pnfisher@redhat.com) wrote:
> > > (1) Is it OK to write Classpath in C++ rather than C?
> >
> > Yes.

I don't see a problem with this. After all, Mozilla does this and is
still extremely portable. We should be careful about using some of the
less widely-deployed features, though, just as Moz is.

> > > (2) Is it OK for Classpath to depend on G++ extensions?
> >
> > Yes.
> 
> I think this should be considered very carefully.  I would like to avoid
> these dependencies if possible.  Particularly any dependencies on gcc.

Agreed.

> Personally, it looks like in the core classes there will be so little
> code that the JNI/CNI thing could be handled with #ifdef CNI/JNI and
> a configure time option added to enable it.  Or a set of macros might
> handled almost everything reasonably well.

I'm wondering if it wouldn't be possible to provide a portable perl
script as part of the Classpath code that would be equivalent to this,
but would output C++ source using JNI. If g++ wanted to support the
-femit-jni feature, the perl code could be turned off in configure, but
classpath could still compile on any C++ compiler.

The only problem that I can see is that the perl code would have to be
very intelligent to figure out that a given class inherited from
java::lang::Object (possibly indirectly). It might be necessary to
*also* include some kind of "magic comment" that would label such
classes to the perl code, and be ignored by g++ which could figure it
out for itself.

Stuart.