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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
