I'd like to second Aaron's concern, though perhaps for somewhat different
reasons.
My impressions are:
1) GC-related problems are sometimes nontrivial to debug. Incorrect use of
especially JNI is likely to result in GC-related problems.
2) It will be far harder to debug those GC-related problems if we can't see
all relevant pieces of the client code, for example because some of them are
generated by the compiler. (Generating them in the preprocessor is OK.
I know how to use gcc -E. Generating them later might also be OK if I can
easily generate the complete C code corresponding to the result.)
3) My impression is that automatically JNIizing code completely is
essentially
impossible. (Adding EnsureLocalCapacity calls appropriately, for example,
seems hard. So does insertion of the appropriate array access primitives.)
My impression from reading the spec is also that JNI,
like essentially all interfaces, is slightly underspecified and evolving.
All of these suggest that there will be subtle bugs related to JNIized code,
and any compiler transformation is likely to end up being nontrivial.
(Fortunately, most JNI code doesn't seem to need the more esoteric pieces,
but some of it will.)
4) I personally hate to debug problems related to using the more subtle
aspects
of C++ operator overloading, particularly when nonstandard "pointers" and
references get into the picture. My experience with this part of the
language
hasn't been positive. It seems to me that this is where the
non-gcc-specific
solutions are headed.
5) It seems to me that anything requiring significant gcc changes will delay
the project appreciably.
Hans
-----Original Message-----
From: Aaron M. Renn [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 12, 2000 6:40 PM
To: Paul Fisher
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Proposal for CNI/JNI problems
Paul Fisher ([EMAIL PROTECTED]) wrote:
> > (1) Is it OK to write Classpath in C++ rather than C?
>
> Yes.
>
> > (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.
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.
--
Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
