[gentoo-java] Re: the new java setup and jni

[Karl Trygve Kalleberg <karltk@gentoo.org>]

Petteri Räty wrote:

> http://lists.debian.org/debian-java/2003/06/msg00005.html

This was what I feared, but hoped was not the case.

> I like more the idea of making symlinks to /usr/include. That would be
> more in line with our switching of vms for compile.

I don't see how symlinks in /usr/include can work. If there are two
users on a system, each with his own prefered VM, how can we export two
sets of symlinks for that system?

Furthermore, it will not be possible to switch the system VM's symlink
during emerge. Consider the situation where root merges a few Java
packages as part of a maintenance cycle, while a regular user (who may
not have set their default VM) compiles a Java program which uses JNI.
The /usr/include/jni.h seen by the user's compilation may flip between
various possible jni.hs, making his program break in mysterious ways.

Of course you can argue that this is an unlikely situation, but what if
root stops the merge with a ctrl-C? Then the /usr/include/jni.h will be
completely wrong, in this scheme.

> What is espicially
> bad about adding them with -I to CFLAGS? That would be the easiest way
> to ensure we are using the jni.h we thought. It would also be better
> if gjc did not install jni.h to /usr/include but that is an upstream
> issue I think.

As you pointed out yourself, some packages try to be smart and find the
jni.h themselves. If they use something like if [ -x ${path}/jni.h ],
putting an -I in CFLAGS won't help much, and the configure script will
probably stop with an error.

If the package tries to find the jni.h by compiling with various -I
options, we may get lucky. The only remaining problem then is ensuring
that we in fact do _not_ have a gcj-installed jni.h in /usr/include,
since that may take precedence.


-- Karl T
-- 
gentoo-java@gentoo.org mailing list