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

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

[Karl Trygve Kalleberg]

Petteri Räty wrote:
> After testing the new java setup I have found that packages using jni
> have problems. The problem is with locating jni.h. There is no standard
> way to find these so this is what two packages I have so far looked at use.
> 
> 1.sys-libs/db
> db looks at path for the location of javac and tries to make the
> location from that.
> 
> 2.dev-java/jdictrayapi
> jdictrayapi expects to find JAVA_HOME in the environment
> 
> So we should decide a solution to this problem. One bad but working
> solution to get stuff working quickly is to play with C(XX)FLAGS. We
> could also make symlinks to /usr/include or we can just patch all the
> packages using jni so that they work how we want them to. java-config -0
> can be used to set the include locations inside the Makefiles.


It would of course be best if whatever solution we come up with doesn't
require a lot of patching.

Radical idea: Can we provide one "standard" jni.h, and put it into, say,
javatoolkit?

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

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

[Karl Trygve Kalleberg]

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

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

[Petteri Räty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Karl Trygve Kalleberg wrote:
> Petteri Räty wrote:
> 
> 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?

True.

> 
> 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.
> 

That is is out of the question then.

> 
> 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.
> 

This is one the issues to discuss at DevJam. Standards are a good thing.
Well you could ensure that -I is the first option to the compiler but I
agree that it we should come up with something more bullet proof.

>
> 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.
>

Let's mail upstream and see what happens.

> 
> 
> -- Karl T

Regards,
Petteri Räty
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDBXfccxLzpIGCsLQRAgYPAJ9tZp7ftQmlU5mRQZTU62BOKEkBEwCghUZU
SIgy+kgCrK5cl6fGJAVCHe0=
=qpms
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

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

[Petteri Räty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter B. West wrote:
> Excuse me, but does this debate relate to the fact that Gentoo Java
> support is borked for users running Sun's Java 5 SDK?
> 
> Peter

It relates to our new java setup for getting Sun's Java 5 SDK working.
And I haven't intended this to be a debate. Sorry if it has sounded like
one.

Regards,
Petteri Räty
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDBhBAcxLzpIGCsLQRAvn3AJ9BwOAae1lCU3IcS0Mu+4dJWk09nQCeKTu7
mKNf0YzgS2ttoC8qvtd+PFM=
=2l47
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

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

[Petteri Räty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter B. West wrote:
> 
> Don't worry about it.  Debate is not a dirty word, as far as I'm concerned.
> 
> However, I am concerned that support for J5 is held up by what, to me,
> are completely peripheral concerns.  I've read the Stallman "philosophy"
> about the Java Trap, and I put it on a par with his contributions to the
> Bitkeeper debate.  I'm using Java 5 *now*, and I'm a new convert to
> Gentoo.  I looks as though I'm better off abandoning ebuilds for Java
> apps and development tools, and going back to the manual maintenance I
> was using under FC3.

Well the java herd always needs more people improving the ebuilds. There
are 151 ebuilds in the dev-java category and only a few active devs. So
please instead of going the manual way, file bugs at bugs.gentoo.org.

> 
> In case you're wondering, I use J5 for open source development.
> 

I don't think there are any problems using J5 for development at the
moment. Just don't use it as the system vm. Of course installing masked
packages can make users a little unconfortable.

>
> Peter
> 

Petteri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDBxbVcxLzpIGCsLQRAgHaAJ9Y2hdYvc9DuzxNYBgTwUN6FYJVogCfY2oY
AiBUrxW5dZPnnQvEQ85CZHQ=
=ViJo
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list

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

[Petteri Räty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter B. West wrote:
>
> I've got around the update problems so far by reverting to 1.4 when
> e-merging.  After emerges, I go back to 1.5 as system VM.  That seems to
> work.  E.g. my ant builds work.  I have had glitches, but I have put
> them down to updates against a 1.5 system VM.  Anything else I should
> look out for?
> 

You can set the vm on a per user basis. java-config -s for that. So use
java-config -S to set the system vm to 1.4 and java-config -s to set
your development vm to 1.5. To get the system vm working you need to
source the env files in .gentoo. That way emerges work fine and you can
still develop with 1.5. Our documentation could be better and hopefully
in the future it is.

>
> I'd love to help out, but my plate is full with my own development
> schedule atm.
>

No problem.

> Peter

Regards,
Petteri Räty
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDB0x7cxLzpIGCsLQRAp7yAKCKmvLTebXuX1E2BgWAEZo9vgiV3wCgiEuZ
tBPY2Upbn9B9lsspsRflPdY=
=DzBc
-----END PGP SIGNATURE-----
-- 
gentoo-java@gentoo.org mailing list