On Dec 21, Stuart Ballard wrote:
> Jochen Hoenicke wrote:
> >
> > I would volunteer to port that package. There are only two native
> > files, so porting it to JNI should be simple.
> >
> > For CNI vs. JNI: One could invent an intermediate language, that could
> > be translated to CNI code or JNI code via a perl script. Using the
> > preprocessor alone (as Stuart suggested) seem impossible (CNI uses C++
> > namespaces and classes like java::util::zip::Deflater::deflate, while
> > JNI uses plain C identifier Java_java_util_zip_Deflater_deflate).
>
> I like the perl approach. Although it might seem hacky, it means we can
> design the meta-language as we want to, rather than using clunky
> preprocessor directives. Even if it were possible to do it with the
> preprocessor, but I know that I for one wouldn't enjoy programming in
> the language that resulted!
>
> I say go for it, and keep us updated on your progress:)
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:
http://www.informatik.uni-oldenburg.de/~delwi/classpath/JCL
convertJCL.pl is the perl script, that does the transformations to
JNI and CNI
Inflater.java the java code.
Inflater.jcl the source code that gets transformed to:
Inflater.c the JNI code.
natInflater.cc the CNI code.
There are some changes against the original natInflater.cc: The
zstream is now stored in an array of bytes instead of using a special
object as native pointer (which may disturb some garbage collectors).
Arrays are accessed via JCL_GetArrayElements and must be released
afterwards. And one has to be much more careful with exceptions and
synchronized blocks, since there is no native exception handling nor
automatic destructor (for calling monitorexit) in C or JNI.
Jochen
