/usr/include/jni.h
The above file is included in sablevm1-dev, libgcj3-dev, and libgcj4-dev.
Kaffe has it at /usr/lib/kaffe/include/jni.h. gcc-snapshot has it at
/usr/lib/gcc-snapshot/include/jni.h.
In discussion with the sablevm maintainer, he maintains that jni.h is a global
file, and is not unique to each vm. However, last night, I was reading the
jni docs, for java 1.4, and discovered that there are different versions of
jni that a vm may support.
In java 1.2 and java 1.4, new features were added that required increasing the
jni version, and adding new functions into jni.h. A program being compiled
for jni can detect the version being compiled for, and modify itself as
needed.
This shows that this file is most definately not global, and definately not
sharable between vms.
So, would all such packages that include jni.h(and other such files they thing
should be global) please move them into a vm-specific location?
Because sablevm and gcj include the same file, this keeps both from being
installed side by side, which I find very annoying, to say the least.
As for the mail in 195350 that says that gcj includes it at
/usr/include/jni.h, so that gcc and g++ can find it by default, I consider
that stupid. Both gcc and g++ have per-compiler/per-version include dirs. I
suggest gcj uses that, instead of using the global location.
I mean, you can install multiple versions of gcc at once, side by side. If,
we follow the thinking that gcj must install to /usr/include/jni.h, then that
precludes installing multiple versions of gcj at once, as well.
Reply to: