libvirt-java bindings

[Daniel Veillard]

  Hi,

I have just started to release and package java bindings for libvirt.
I have made a request for review for Fedora on the new package:
  https://bugzilla.redhat.com/show_bug.cgi?id=453119

I found the exercise rather hard, JNI is of course on the edge of the Java
land, but it's hard to find good resources to look at for Java bindings
in Fedora, the gnome-java stuff seems very specific, and a lot of packages
basically rely on gcj for compilation of any JNI stuff.

I would like something more flexible, to that end I added some JDK dynamic
detection in configure.in for my package, which then allows to guess the
jni.h and jni_md.h based on the javah and javac used to generate the bindings
(so things should stay consistent).
In the spec file I used the following:

%define java	java
and
Requires:	%{java} >= 1.5.0
BuildRequires:	%{java}-devel >= 1.5.0

 to easilly allow the user to specify more strictly what java development
package to use. I don't know if this is sufficient in general for the
previous versions of Fedora, it seems to work with java-1.6.0-openjdk
in F-9 or something as old as java-1.5.0-ibm-1.5.0.7 on a RHEL-4 box,
but the java class compilations break for example with java-1.5.0-gcj [-devel]
on Fedora-8 (didn't tried icedtea yet, though I guess that would work)
this looks related to dependancies when compiling a bunch of .java
together in one command as 

   /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java
   2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14)
   	credType= new  VirConnectCredential.VirConnectCredentialType[] {
	^^^^^^^^
	credType cannot be resolved

though VirConnectCredential.java is there and defines the type.

  Portability tricks and eyeballs for the review would be very welcome !
(as well as patches to improve the package source of course but that
would be best conducted on the libvirt list).

   thanks in advance,

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Andrew Haley]

Daniel Veillard wrote:
>    the java class compilations break for example with java-1.5.0-gcj
> [-devel]
>  on Fedora-8 (didn't tried icedtea yet, though I guess that would work)
>  this looks related to dependancies when compiling a bunch of .java
>  together in one command as 
>  
>     /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java
>     2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14)
>     	credType= new  VirConnectCredential.VirConnectCredentialType[] {
>  	^^^^^^^^
>  	credType cannot be resolved
>  
>  though VirConnectCredential.java is there and defines the type. 
Hmm.  I think we need to find out if this is a real bug in ecj, and
fix it if so.  I can't remember seeing anything like this before.

Can you create a stand-alone test case that shows this failure?  I can't
figure out how to do so.

I don't think we should target a particular Java compiler if that can be
avoided.

Andrew.

[Benjamin Reed]

Daniel Veillard wrote:

>    Portability tricks and eyeballs for the review would be very
> welcome ! 
It also still wouldn't work with the official sun RPMs, which I wish we 
had some kind of simpler solution for, interoperability-wise.

At least making it a define of some kind would make it easy to generate 
the packages twice, once for fedora deps, and once for sun deps.  ie, 
instead of:

>  %define java	java 
...you could do something like this instead:

%{!?java_requires:%define java_requires java}
%{!?java_buildrequires:%define java_buildrequires java-devel}
%{!?java_min_version:%define java_min_version 1.5.0}

>  and
>  Requires:	%{java} >= 1.5.0
>  BuildRequires:	%{java}-devel >= 1.5.0 
...and then:

Requires: %{java_requires} >= %{java_min_version}
BuildRequires: %{java_buildrequires} >= %{java_min_version}


This lets you do:

   rpmbuild \
     --define "java_requires jre" \
     --define "java_buildrequires jdk" \
     --define "java-min_version 1.6.0" \
     -ba mypackage.spec

...to override the defaults.  (I think that's the right syntax...)

-- 
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/

[David Walluck]

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

Daniel Veillard wrote:
| I would like something more flexible, to that end I added some JDK dynamic
| detection in configure.in for my package, which then allows to guess the
| jni.h and jni_md.h based on the javah and javac used to generate the
bindings
| (so things should stay consistent).
| In the spec file I used the following:

There is no need since java and java-devel are virtual Provides provided
by every compliant JDK, so the user is already allowed to choose the JDK
that they want to build with.

Also, there are macros that should be used when refering to the JDK so
that you pick up the default JDK used for building and not the current
default alternative (e.g., %{java_home}, %{java}, %{javac}, %{jar}).

Unfortunately, there are recent packages passing the Fedora review that
directly specify java-1.6.0-openjdk-devel as the JDK and I personally
don't like this.

I think that this comes from two schools of thought: one group wants to
tie the Fedora package even more tightly to Fedora and the other wants
to leave the options open. Since Fedora more-or-less has only one JDK
(or two counting GCJ which is optional), this benefit is mostly
theoretical, but you can see from the current discussion that it can be
useful. Similarly, since Fedora can force the default JDK setup at build
time through the build system, although the packages are technically not
as flexible as they could be, it's never really a problem in practice.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhqWlAACgkQItObMyg2XCUpNgCghlrnFGtwJPikTBuBxLCCNLLe
> 3r0AnRs5bIeVxAruG1Ri/bkhQuYwY/63
> =6Tqq
> -----END PGP SIGNATURE-----

[Mary Ellen Foster]

2008/7/1 David Walluck <david(a)zarb.org&gt;:
>  Unfortunately, there are recent packages passing the Fedora review
> that
>  directly specify java-1.6.0-openjdk-devel as the JDK and I personally
>  don't like this. 
I have one recent package that does this (specifies openjdk on F9+ and
icedtea on F8) and one that doesn't (just wants java >= 1.5). The
first package uses JNI and needs a Sun-like JVM to work (or at least
it took more autotools hacking than I cared to try to make it work),
and if I just put Requires: java it tended to grab gcj. I guess I
could also put java > 1.5, but the issue isn't the 1.5-ness, it's the
Sun-style JNI classes.

(The packages are pl-jpl and ice-java, respectively, if you're wondering).

MEF

-- 
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh

[Mary Ellen Foster]

[ oops, just replied to Andrew the first time ... ]

2008/7/1 Andrew Haley <aph(a)redhat.com&gt;:
>  Daniel Veillard wrote:
> >   the java class compilations break for example with java-1.5.0-gcj [-devel]
> > on Fedora-8 (didn't tried icedtea yet, though I guess that would work)
> > this looks related to dependancies when compiling a bunch of .java
> > together in one command as
> >
> >    /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java
> >    2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14)
> >       credType= new  VirConnectCredential.VirConnectCredentialType[] {
> >       ^^^^^^^^
> >       credType cannot be resolved
> >
> > though VirConnectCredential.java is there and defines the type.
>
>  Hmm.  I think we need to find out if this is a real bug in ecj, and
>  fix it if so.  I can't remember seeing anything like this before.
>
>  Can you create a stand-alone test case that shows this failure?  I can't
>  figure out how to do so. 
I think the problem might actually be a lack of "-source 1.5" on the
javac line, actually. Without that, it doesn't seem to like the "enum"
declarations and doesn't create any of the enum classes, resulting in
the above error (and, if you scroll down, errors about the enum
declarations too).

This is testing with java-1.5.0-gcj-devel-1.5.0.0-17.fc8 on Fedora 8, FWIW.

MEF

-- 
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh

[Andrew Haley]

Mary Ellen Foster wrote:
>  [ oops, just replied to Andrew the first time ... ]
>  
>  2008/7/1 Andrew Haley <aph(a)redhat.com&gt;:
> > Daniel Veillard wrote:
> >>   the java class compilations break for example with java-1.5.0-gcj [-devel]
> >> on Fedora-8 (didn't tried icedtea yet, though I guess that would work)
> >> this looks related to dependancies when compiling a bunch of .java
> >> together in one command as
> >>
> >>    /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java
> >>    2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14)
> >>       credType= new  VirConnectCredential.VirConnectCredentialType[] {
> >>       ^^^^^^^^
> >>       credType cannot be resolved
> >>
> >> though VirConnectCredential.java is there and defines the type.
> > Hmm.  I think we need to find out if this is a real bug in ecj, and
> > fix it if so.  I can't remember seeing anything like this before.
> >
> > Can you create a stand-alone test case that shows this failure?  I can't
> > figure out how to do so.
>  
>  I think the problem might actually be a lack of "-source 1.5" on the
>  javac line, actually. Without that, it doesn't seem to like the "enum"
>  declarations and doesn't create any of the enum classes, resulting in
>  the above error (and, if you scroll down, errors about the enum
>  declarations too).
>  
>  This is testing with java-1.5.0-gcj-devel-1.5.0.0-17.fc8 on Fedora 8, FWIW. 
Okay, thanks.  That should be easy to fix then.

Daniel, please try that and report.

I could have sworn that we changed the default for ecj to 1.5.  We
surely should have done.

Andrew.

[Benjamin Reed]

David Walluck wrote:

>  Also, there are macros that should be used when refering to the JDK
> so
>  that you pick up the default JDK used for building and not the current
>  default alternative (e.g., %{java_home}, %{java}, %{javac}, %{jar}). 
Aha, I was not aware of these defines.

>  Unfortunately, there are recent packages passing the Fedora review
> that
>  directly specify java-1.6.0-openjdk-devel as the JDK and I personally
>  don't like this.
>  
>  I think that this comes from two schools of thought: one group wants to
>  tie the Fedora package even more tightly to Fedora and the other wants
>  to leave the options open. Since Fedora more-or-less has only one JDK
>  (or two counting GCJ which is optional), this benefit is mostly
>  theoretical, but you can see from the current discussion that it can be
>  useful. Similarly, since Fedora can force the default JDK setup at build
>  time through the build system, although the packages are technically not
>  as flexible as they could be, it's never really a problem in practice. 
My main issue is that as a package maintainer, if I want to support 
Fedora officially *and* other RPM-based distributions (through our own 
yum repository) I have doubled my workload since I need to make packages 
that use fedora-style dependencies for fedora, and package that use 
sun-jdk-style dependencies for everyone else.  Right now I depend on 
"jdk" and everything works peachy everywhere, we make a .noarch.rpm and 
it runs on every supported RPM platform on the planet.

Depending on java-1.6.0-openjdk-devel is the worst of the options, from 
a 3rd-party-packager point of view.  However, now that I know about the 
fedora %{java_home} macros, perhaps a better option is to provide 
fallback macros for various compatibility levels.

IE, for building my generic everyone-but-fedora packages I would have a 
"sun-java-macros" set (in ~/.rpmmacros?) that would set %{java_home} to 
/usr/java/jdk1.6.0_05, %{jdk} to jdk (the sun package name) 
%{jdk_version} to 2000:1.6.0_05 and so on, and do:

Requires: %{jre} >= %{jre_version}
BuildRequires: %{jdk} >= %{jdk_version}

%build
JAVA_HOME=%{java_home} mvn install assembly:directory-inline


...and on fedora, it would fill those macros in to use the 
openjdk-provided deps, or if someone needs something specific, they can 
set %{jre} or %{jdk} to a specific package name.

It still wouldn't leave me with a universal "opennms.noarch.rpm" which 
would be best, but it would simplify generating distro-specific rpms.

Not that I can't generate spec files to work with fedora with a script 
or something, it just seems really lame to have to special case "fc9" vs 
"!fc9" specifically.  =)

-- 
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/

[David Walluck]

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

Benjamin Reed wrote:
| David Walluck wrote:
|
|> Also, there are macros that should be used when refering to the JDK so
|> that you pick up the default JDK used for building and not the current
|> default alternative (e.g., %{java_home}, %{java}, %{javac}, %{jar}).
|
| Aha, I was not aware of these defines.

These should be available through the jpackage macros from
jpackage-utils (see /etc/rpm/macros.jpackage).

| My main issue is that as a package maintainer, if I want to support
| Fedora officially *and* other RPM-based distributions (through our own

Not at all. If you follow the JPackage conventions you will support any
distribution which carries jpackage-utils. These include: ALT, Fedora,
Mandriva, PCLOS, Red Hat, Suse, and possibly others.

This means using java-devel like I said and not relying on the Sun
conventions (this also allows you to support multiple JDK versions and
not just multiple Linux distributions with a single JDK version). Also,
since Sun supported the DLJ Java packages, at least Mandriva is shipping
JPackage-compliant DLJ Sun Java bundles with their OS which would be far
superior to any Sun packaging offering due to JPackage compliance.

This also means, like I said in a previous email, that I don't think
additional macros are needed, but check the macros file first and see if
you think anything is missing.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhqcP0ACgkQItObMyg2XCVXcQCgiVGskRSE2wj8lAR8vwgy0+TF
> 1kIAoKshQHjcf/AGOhv6EbU0L1RACWk0
> =dkhY
> -----END PGP SIGNATURE-----

[David Walluck]

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

Mary Ellen Foster wrote:
| I have one recent package that does this (specifies openjdk on F9+ and
| icedtea on F8) and one that doesn't (just wants java >= 1.5). The
| first package uses JNI and needs a Sun-like JVM to work (or at least
| it took more autotools hacking than I cared to try to make it work),
| and if I just put Requires: java it tended to grab gcj. I guess I
| could also put java > 1.5, but the issue isn't the 1.5-ness, it's the
| Sun-style JNI classes.

This is not an issue with the java-devel packages, but rather an issue
with either the upstream configure or an issue with the GCJ packaging.

If it is lack of JNI support in GCJ, that is one thing. If it is simply
that the package is expecting a differnt layout that is another.

| (The packages are pl-jpl and ice-java, respectively, if you're wondering).

I was not referring specifically to your packages. But I also haven't
been able to look and see if there is a simple fix available for GCJ.
You should raise the issue on this list though because there are people
here who can help with either issue.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhqcokACgkQItObMyg2XCXywACfTMLzyrvRTVT08cw6zwNZmCum
> tK0An1nRpk0WuFIlLRJljVaZjTKQSZTO
> =/Hdt
> -----END PGP SIGNATURE-----

[Benjamin Reed]

David Walluck wrote:

>  These should be available through the jpackage macros from
>  jpackage-utils (see /etc/rpm/macros.jpackage). 
Ah, ok.

>  | My main issue is that as a package maintainer, if I want to
> support
>  | Fedora officially *and* other RPM-based distributions (through our own
>  
>  Not at all. If you follow the JPackage conventions you will support any
>  distribution which carries jpackage-utils. These include: ALT, Fedora,
>  Mandriva, PCLOS, Red Hat, Suse, and possibly others. 
OK, I'll give the JPackage stuff another look.

My previous foray into jpackage was a mess of hand-building from 
src.rpms and other craziness just to get around things that were already 
provided easily from sun or otherwise, and I must admit, I was very 
turned off by the amount of manual work it took to install something 
when the whole point is to automate installation.  =)

If the tools have gotten better, great, I'll give it another shot.

>  This also means, like I said in a previous email, that I don't
> think
>  additional macros are needed, but check the macros file first and see if
>  you think anything is missing. 
Yeah, if everything conforms to the java/java-devel stuff, then it 
should work.

Thanks for the response, I'll do more investigation.

-- 
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/

[David Walluck]

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

Benjamin Reed wrote:
| My previous foray into jpackage was a mess of hand-building from
| src.rpms and other craziness just to get around things that were already
| provided easily from sun or otherwise, and I must admit, I was very
| turned off by the amount of manual work it took to install something
| when the whole point is to automate installation.  =)

If you are looking for a single monolithic package with no dependencies,
then it will not do that (but then generally neither will Fedora or any
other RPM-based distribution).

Otherwise, raise the specific concerns as you come across them and we
will see if it has to be that way or if there is some technical solution.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhqeS4ACgkQItObMyg2XCXS2gCfc8PaiuCupRfRvSeIjz9uhsWR
> SZoAn3kEJeY4+VPomR2KT1Df72I3S5B/
> =0ETY
> -----END PGP SIGNATURE-----

[Farkas Levente]

Daniel Veillard wrote:
>    Hi,
>  
>  I have just started to release and package java bindings for libvirt.
>  I have made a request for review for Fedora on the new package:
>    https://bugzilla.redhat.com/show_bug.cgi?id=453119
>  
>  I found the exercise rather hard, JNI is of course on the edge of the Java
>  land, but it's hard to find good resources to look at for Java bindings
>  in Fedora, the gnome-java stuff seems very specific, and a lot of packages
>  basically rely on gcj for compilation of any JNI stuff. 
you may look into jna. gstreamer-java use it. it's much simpler, easier 
then jni without the above problems.


-- 
   Levente                               "Si vis pacem para bellum!"

[Daniel Veillard]

On Tue, Jul 01, 2008 at 05:36:56PM +0100, Mary Ellen Foster wrote:
>  [ oops, just replied to Andrew the first time ... ]
>  
>  2008/7/1 Andrew Haley <aph(a)redhat.com&gt;:
>  > Daniel Veillard wrote:
>  >>   the java class compilations break for example with java-1.5.0-gcj [-devel]
>  >> on Fedora-8 (didn't tried icedtea yet, though I guess that would work)
>  >> this looks related to dependancies when compiling a bunch of .java
>  >> together in one command as
>  >>
>  >>    /usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java
>  >>    2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14)
>  >>       credType= new  VirConnectCredential.VirConnectCredentialType[] {
>  >>       ^^^^^^^^
>  >>       credType cannot be resolved
>  >>
>  >> though VirConnectCredential.java is there and defines the type.
>  >
>  > Hmm.  I think we need to find out if this is a real bug in ecj, and
>  > fix it if so.  I can't remember seeing anything like this before.
>  >
>  > Can you create a stand-alone test case that shows this failure?  I can't
>  > figure out how to do so.
>  
>  I think the problem might actually be a lack of "-source 1.5" on the
>  javac line, actually. Without that, it doesn't seem to like the "enum"
>  declarations and doesn't create any of the enum classes, resulting in
>  the above error (and, if you scroll down, errors about the enum
>  declarations too). 
  Haha, yes !
This fixes it. I still gets 3 warnings but not a blocker :-)

>  This is testing with java-1.5.0-gcj-devel-1.5.0.0-17.fc8 on Fedora 8,
> FWIW. 
  Right :-)
If I understand correctly enum was added in Java 1.5, if I ask about
the version I get 
laptop:~/libvirt-java/src -> /usr/bin/javac -version
Eclipse Java Compiler 0.771, 3.3.0, Copyright IBM Corp 2000, 2007. All rights reserved.

  Maybe the most portable way to fix this is to force that version flag
when javac is the Eclipse compiler.

  I think I will augment the checkings done in configure.in accordingly

   thanks !

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Daniel Veillard]

On Tue, Jul 01, 2008 at 12:24:49PM -0400, David Walluck wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Daniel Veillard wrote:
>  | I would like something more flexible, to that end I added some JDK dynamic
>  | detection in configure.in for my package, which then allows to guess the
>  | jni.h and jni_md.h based on the javah and javac used to generate the
>  bindings
>  | (so things should stay consistent).
>  | In the spec file I used the following:
>  
>  There is no need since java and java-devel are virtual Provides provided
>  by every compliant JDK, so the user is already allowed to choose the JDK
>  that they want to build with.
>  
>  Also, there are macros that should be used when refering to the JDK so
>  that you pick up the default JDK used for building and not the current
>  default alternative (e.g., %{java_home}, %{java}, %{javac}, %{jar}). 
  Hum, interesting, butthat's very dependant on the build environment.
For example if I rebuild the RPM for RHELv4 those macro define won't exist
I don't think I should rely on this for a really generic spec file.

>  Unfortunately, there are recent packages passing the Fedora review
> that
>  directly specify java-1.6.0-openjdk-devel as the JDK and I personally
>  don't like this.
>  
>  I think that this comes from two schools of thought: one group wants to
>  tie the Fedora package even more tightly to Fedora and the other wants
>  to leave the options open. Since Fedora more-or-less has only one JDK
>  (or two counting GCJ which is optional), this benefit is mostly
>  theoretical, but you can see from the current discussion that it can be
>  useful. Similarly, since Fedora can force the default JDK setup at build
>  time through the build system, although the packages are technically not
>  as flexible as they could be, it's never really a problem in practice. 
  I think the distro build can already define its own policy of what
package should be used when there is a java/java-devel BuildRequires
just by the way it selects the package used to create the build root.
So %{java_home}, %{java}, %{javac}, %{jar} to me are in a sense redundant
in that enviroment.
And outside of the distro build the macros are not available and that's
where the user selection should be done, so this doesn't help much in the
case of a manual user rpmbuild, except maybe if one uses them to override
the alternative default. 
  I guess I need to think a bit more about it, but i'm firmly in the camp
of those who think the package should be distribution agnostic as much as
possible.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Daniel Veillard]

On Tue, Jul 01, 2008 at 09:40:53PM +0200, Farkas Levente wrote:
>  Daniel Veillard wrote:
>  >  Hi,
>  >
>  >I have just started to release and package java bindings for libvirt.
>  >I have made a request for review for Fedora on the new package:
>  >  https://bugzilla.redhat.com/show_bug.cgi?id=453119
>  >
>  >I found the exercise rather hard, JNI is of course on the edge of the Java
>  >land, but it's hard to find good resources to look at for Java bindings
>  >in Fedora, the gnome-java stuff seems very specific, and a lot of packages
>  >basically rely on gcj for compilation of any JNI stuff.
>  
>  you may look into jna. gstreamer-java use it. it's much simpler, easier 
>  then jni without the above problems. 
  Well back in 97 we tried to avoid JNI in the Kaffe project, the 
alternative was more elegant, easier, faster. I think everybody outside
of java has hoped or tried to develop different bindings mechanism,
unfortunately none prevailed, at this point I will stick with JNI,

  thanks :-)

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Mary Ellen Foster]

2008/7/1 David Walluck <david(a)zarb.org&gt;:
>  Mary Ellen Foster wrote:
>  | I have one recent package that does this (specifies openjdk on F9+ and
>  | icedtea on F8) and one that doesn't (just wants java >= 1.5). The
>  | first package uses JNI and needs a Sun-like JVM to work (or at least
>  | it took more autotools hacking than I cared to try to make it work),
>  | and if I just put Requires: java it tended to grab gcj. I guess I
>  | could also put java > 1.5, but the issue isn't the 1.5-ness, it's the
>  | Sun-style JNI classes.
>
>  This is not an issue with the java-devel packages, but rather an issue
>  with either the upstream configure or an issue with the GCJ packaging.
>
>  If it is lack of JNI support in GCJ, that is one thing. If it is simply
>  that the package is expecting a differnt layout that is another. 
I just did a bit of hacking, and it is possible to build the package
against gcj instead of openjdk. There were two things to fix:
- the "configure" script followed symlinks from javac to find the JNI
include dir. Since the symlinks for gcj ground out at /usr/bin/ecj, it
ended up looking for /usr/include/jni.h.
- It also wanted to hardcode "-ljava -lverify -ljvm" on the gcc line,
which isn't right for gcj

But I'm not sure if I want to make these modifications to the package.
If I build a JNI program against gcj, can the resulting .so be used
with Sun-like JVMs? How does this work? Is it documented anywhere?

Thanks,

MEF

-- 
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh

[Andrew Haley]

Mary Ellen Foster wrote:
>  2008/7/1 David Walluck <david(a)zarb.org&gt;:
> > Mary Ellen Foster wrote:
> > | I have one recent package that does this (specifies openjdk on F9+ and
> > | icedtea on F8) and one that doesn't (just wants java >= 1.5). The
> > | first package uses JNI and needs a Sun-like JVM to work (or at least
> > | it took more autotools hacking than I cared to try to make it work),
> > | and if I just put Requires: java it tended to grab gcj. I guess I
> > | could also put java > 1.5, but the issue isn't the 1.5-ness, it's the
> > | Sun-style JNI classes.
> >
> > This is not an issue with the java-devel packages, but rather an issue
> > with either the upstream configure or an issue with the GCJ packaging.
> >
> > If it is lack of JNI support in GCJ, that is one thing. If it is simply
> > that the package is expecting a differnt layout that is another.
>  
>  I just did a bit of hacking, and it is possible to build the package
>  against gcj instead of openjdk. There were two things to fix:
>  - the "configure" script followed symlinks from javac to find the JNI
>  include dir. Since the symlinks for gcj ground out at /usr/bin/ecj, it
>  ended up looking for /usr/include/jni.h. 
Hmm.  This package assumes that the chain of symlinks ends at the installed
binary, which must be in the jdk dir.

/usr/bin/javac -->
/etc/alternatives/javac -->
/usr/lib/jvm/java-1.4.2-gcj/bin/javac -->
/usr/bin/ecj

?

>  - It also wanted to hardcode "-ljava -lverify -ljvm" on the
> gcc line,
>  which isn't right for gcj 
No.  I'm surprised it's right for Java either; libjvm and libverify
I'd expect.

>  But I'm not sure if I want to make these modifications to the
> package.
>  If I build a JNI program against gcj, can the resulting .so be used
>  with Sun-like JVMs? How does this work? Is it documented anywhere? 
I think so.

Andrew.

[Mary Ellen Foster]

2008/7/2 Andrew Haley <aph(a)redhat.com&gt;:
>  Mary Ellen Foster wrote:
> > - the "configure" script followed symlinks from javac to find the JNI
> > include dir. Since the symlinks for gcj ground out at /usr/bin/ecj, it
> > ended up looking for /usr/include/jni.h.
>
>  Hmm.  This package assumes that the chain of symlinks ends at the installed
>  binary, which must be in the jdk dir.
>
>  /usr/bin/javac -->
>  /etc/alternatives/javac -->
>  /usr/lib/jvm/java-1.4.2-gcj/bin/javac -->
>  /usr/bin/ecj
>
>  ? 
Yes. The comment in the configure script says "find the include
directory relative to the javac executable", and it loops through
links until it finds an actual binary. I hacked it for the moment by
adding
    if [ `basename $_slink` = "ecj" ]; then break; fi
(where $_slink is the target of the current link) and it seems to work fine.

> > But I'm not sure if I want to make these modifications to the
> package.
> > If I build a JNI program against gcj, can the resulting .so be used
> > with Sun-like JVMs? How does this work? Is it documented anywhere?
>
>  I think so. 
Hmm. Maybe I'll give that a try this afternoon then.

Thanks,

MEF

-- 
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh

[Dalibor Topic]

Daniel Veillard wrote:
>  On Tue, Jul 01, 2008 at 09:40:53PM +0200, Farkas Levente wrote:
>    
> > Daniel Veillard wrote:
> >     
> >>  Hi,
> >>
> >> I have just started to release and package java bindings for libvirt.
> >> I have made a request for review for Fedora on the new package:
> >>  https://bugzilla.redhat.com/show_bug.cgi?id=453119
> >>
> >> I found the exercise rather hard, JNI is of course on the edge of the Java
> >> land, but it's hard to find good resources to look at for Java bindings
> >> in Fedora, the gnome-java stuff seems very specific, and a lot of packages
> >> basically rely on gcj for compilation of any JNI stuff.
> >>       
> > you may look into jna. gstreamer-java use it. it's much simpler, easier 
> > then jni without the above problems.
> >     
>
>    Well back in 97 we tried to avoid JNI in the Kaffe project, the 
>  alternative was more elegant, easier, faster. I think everybody outside
>  of java has hoped or tried to develop different bindings mechanism,
>  unfortunately none prevailed, at this point I will stick with JNI, 
I'll sing
the praise for JNA, as it is VM-independent, so doesn't suffer 
from the
problem most other (usually vm-specific) JNI-replacements do.

cheers,
dalibor topic


-- 
*******************************************************************
Dalibor Topic                   Tel: [phone]
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: [phone]
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:[e-mail]
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring

[Daniel Veillard]

On Wed, Jul 02, 2008 at 01:04:28PM +0200, Dalibor Topic wrote:
>  Daniel Veillard wrote:
>  >On Tue, Jul 01, 2008 at 09:40:53PM +0200, Farkas Levente wrote:
>  >  
>  >>Daniel Veillard wrote:
>  >>    
>  >>> Hi,
>  >>>
>  >>>I have just started to release and package java bindings for libvirt.
>  >>>I have made a request for review for Fedora on the new package:
>  >>> https://bugzilla.redhat.com/show_bug.cgi?id=453119
>  >>>
>  >>>I found the exercise rather hard, JNI is of course on the edge of the 
>  >>>Java
>  >>>land, but it's hard to find good resources to look at for Java bindings
>  >>>in Fedora, the gnome-java stuff seems very specific, and a lot of 
>  >>>packages
>  >>>basically rely on gcj for compilation of any JNI stuff.
>  >>>      
>  >>you may look into jna. gstreamer-java use it. it's much simpler, easier 
>  >>then jni without the above problems.
>  >>    
>  >
>  >  Well back in 97 we tried to avoid JNI in the Kaffe project, the 
>  >alternative was more elegant, easier, faster. I think everybody outside
>  >of java has hoped or tried to develop different bindings mechanism,
>  >unfortunately none prevailed, at this point I will stick with JNI,
>  I'll sing the praise for JNA, as it is VM-independent, so doesn't suffer 
>  from the
>  problem most other (usually vm-specific) JNI-replacements do. 
  haha, well you're obviously in a good position to sing that song now :)

Looking at the example, yes this looks way nicer, but having that JNI code
now I'm not sure I want to rewrite the thing.
  One interesting thing in my case is that JNA is compatible up to 1.4
while our bindings are restricted to 1.5+ since they use enums (currently
this just mean I can't compile with gcj in the RHEL releases, but that's 
a point in JNA favour)

  cheers,

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Daniel Veillard]

On Wed, Jul 02, 2008 at 11:30:09AM +0100, Andrew Haley wrote:
>  Mary Ellen Foster wrote:
>  > 2008/7/1 David Walluck <david(a)zarb.org&gt;:
>  >> Mary Ellen Foster wrote:
>  >> | I have one recent package that does this (specifies openjdk on F9+ and
>  >> | icedtea on F8) and one that doesn't (just wants java >= 1.5). The
>  >> | first package uses JNI and needs a Sun-like JVM to work (or at least
>  >> | it took more autotools hacking than I cared to try to make it work),
>  >> | and if I just put Requires: java it tended to grab gcj. I guess I
>  >> | could also put java > 1.5, but the issue isn't the 1.5-ness, it's
> the
>  >> | Sun-style JNI classes.
>  >>
>  >> This is not an issue with the java-devel packages, but rather an issue
>  >> with either the upstream configure or an issue with the GCJ packaging.
>  >>
>  >> If it is lack of JNI support in GCJ, that is one thing. If it is simply
>  >> that the package is expecting a differnt layout that is another.
>  > 
>  > I just did a bit of hacking, and it is possible to build the package
>  > against gcj instead of openjdk. There were two things to fix:
>  > - the "configure" script followed symlinks from javac to find the JNI
>  > include dir. Since the symlinks for gcj ground out at /usr/bin/ecj, it
>  > ended up looking for /usr/include/jni.h.
>  
>  Hmm.  This package assumes that the chain of symlinks ends at the installed
>  binary, which must be in the jdk dir.
>  
>  /usr/bin/javac -->
>  /etc/alternatives/javac -->
>  /usr/lib/jvm/java-1.4.2-gcj/bin/javac -->
>  /usr/bin/ecj 
  I changed libvirt-java configure.in to walk the chain of symlinks starting
from javah/javac to find the JDK location and its includes.
  That seems to work pretty well in practice, and with that in place and the
-source 1.5 cleanup for ecj the package build and generates rpms without
problems on a variety of platforms:

   RHEL-4: works with IBM 1.5.0
   RHEL-5: works with IBM/SUN/BEA 1.5.0
           fails with gcj because it's 1.4 and the bindings use enums
   Fedora8: works with IcedTea-1.7 and java-1.5.0-gcj-devel
   Fedora9: works with OpenJDK-1.6.0 and java-1.5.0-gcj-devel

  thanks for the feedback !

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Mary Ellen Foster]

2008/7/2 Mary Ellen Foster <foster(a)in.tum.de&gt;:
>  2008/7/2 Andrew Haley <aph(a)redhat.com&gt;:
> >> But I'm not sure if I want to make these modifications to the package.
> >> If I build a JNI program against gcj, can the resulting .so be used
> >> with Sun-like JVMs? How does this work? Is it documented anywhere?
> >
> > I think so.
>
>  Hmm. Maybe I'll give that a try this afternoon then. 
Well, would you look at that -- JNI shared objects built against GCJ
do indeed seem to work just fine when I run them with IcedTea or
OpenJDK. That's cool! So my Java sub-package can now be enabled on F8
ppc{64} as well, which is a bonus.

MEF

-- 
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh

[Andrew Haley]

Mary Ellen Foster wrote:
>  2008/7/2 Mary Ellen Foster <foster(a)in.tum.de&gt;:
> > 2008/7/2 Andrew Haley <aph(a)redhat.com&gt;:
> >>> But I'm not sure if I want to make these modifications to the package.
> >>> If I build a JNI program against gcj, can the resulting .so be used
> >>> with Sun-like JVMs? How does this work? Is it documented anywhere?
> >> I think so.
> > Hmm. Maybe I'll give that a try this afternoon then.
>  
>  Well, would you look at that -- JNI shared objects built against GCJ
>  do indeed seem to work just fine when I run them with IcedTea or
>  OpenJDK. That's cool! So my Java sub-package can now be enabled on F8
>  ppc{64} as well, which is a bonus. 
Excellent.  We aim to please.  :-)

Andrew.

[David Walluck]

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

Daniel Veillard wrote:
| And outside of the distro build the macros are not available and that's
| where the user selection should be done, so this doesn't help much in the
| case of a manual user rpmbuild, except maybe if one uses them to override
| the alternative default.

To my knowledge they are available. At least allow the user to set
JAVA_HOME. This is much cleaner than a hack on following that has been
proven not to work ever since IBM JDK 1.4.

|   I guess I need to think a bit more about it, but i'm firmly in the camp
| of those who think the package should be distribution agnostic as much as
| possible.

It is distribution agnostic. Were the 6+ RPM-based distributions I
mentioned in a previous email not agnostic enough? Even Debian/Ubuntu
follow the same layout for JVM's.

But you were speaking of an RPM build, so that covers ever major RPM
distro I know of.

And if you allow $JAVA_HOME and --with-java-home= as a configure option,
and try /usr/lib/jvm/java first if none is specficed, then you will also
support Ubuntu out of the box without resorting to a hack.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhrq6IACgkQItObMyg2XCXaRwCfSZSBoPkDLORYmSElqeiVpaUP
> xh8Ani1hNq8Jb55LZ8pOTbhE2gX7R58r
> =A+P5
> -----END PGP SIGNATURE-----

[David Walluck]

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

Daniel Veillard wrote:
|   I changed libvirt-java configure.in to walk the chain of symlinks
starting
| from javah/javac to find the JDK location and its includes.
|   That seems to work pretty well in practice, and with that in place
and the
| -source 1.5 cleanup for ecj the package build and generates rpms without
| problems on a variety of platforms:

I thought Mary Ellen's email was to demonstrate how this method was bad,
but you took this as a reason to adaopt it. Unless you think
/usr/bin/ecj is not a valid Java compiler, then it's the method that's
broken, not the compiler location.

It's your software, so you can do what you want. I am just telling you
how Java on Linux has been working for the past five or so years.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhrrIcACgkQItObMyg2XCVSbACfW9Uya5lHvt+8AktUP01Fdnj5
> iFcAn1KYFODD5FwU9ZbWY5OhYhX27Jr+
> =rDX4
> -----END PGP SIGNATURE-----

[Daniel Veillard]

On Wed, Jul 02, 2008 at 12:27:51PM -0400, David Walluck wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Daniel Veillard wrote:
>  |   I changed libvirt-java configure.in to walk the chain of symlinks
>  starting
>  | from javah/javac to find the JDK location and its includes.
>  |   That seems to work pretty well in practice, and with that in place
>  and the
>  | -source 1.5 cleanup for ecj the package build and generates rpms without
>  | problems on a variety of platforms:
>  
>  I thought Mary Ellen's email was to demonstrate how this method was bad,
>  but you took this as a reason to adaopt it. Unless you think
>  /usr/bin/ecj is not a valid Java compiler, then it's the method that's
>  broken, not the compiler location. 
  Why would I think ecj is not a valid Java compiler ? Stop assuming
the only problem with ecj was that it needed the -source 1.5 flags.

>  It's your software, so you can do what you want. I am just
> telling you
>  how Java on Linux has been working for the past five or so years. 
  No, you did not tell me !

Moreover that knowledge you have accumulated for that time is *not*
availbale easilly as far as I can tell.
You have not provided answers to my problems, you have no right to vent
some frustrations if I appear to not have followed your indications (which
ones ? where ?).

  I think what I have done was reasonable, I went to the Fedora Packaging
guidelines, read and followed indications provided by
  /usr/share/doc/jpackage-utils-1.7.5/jpackage-utils-policy
But I had 3 concrete real problems I needed a solution for:

 1/ I needed a way to give the user the flexibility for the JDK used
 2/ I needed the include paths for the JNI headers
 3/ I needed a -source 1.5 options when compiling against the Eclipse compiler
    (thanks a lot Mary for the solution !)

Your answer as I understood it was:
  - that I should ignore 1/
  - that there were some RPM macros (undefined, just a list of macro names)
  - then started to vent about the fact that people don't do the Right Thing

Please go reread your answer, that's really what is in your reply to my mail !

Sorry maybe you're the authority on the topic, but based on your answer
that was far from obvious !
My approach has been to read the (apparently) appropriate Fedora packaging
page in the Wiki
  http://fedoraproject.org/wiki/Packaging/Java
then read and follow the JPackage policy
  /usr/share/doc/jpackage-utils-1.7.5/jpackage-utils-policy
and since I still didn't found answers to 1/ 2/ /3 I asked on IRC, which is
why I ended up subscribing to that list and asked.

 Now please stop assuming people know what you know (otherwise we would not
be there asking), save one hour of your time to write down what you know
people should do when packaging JNI related sources (including answers to
at least 1/ and 2/) both for configure.in and for the spec file, with 
examples and explanations of what the various macro do. You will save a lot
of time of people who just try to do the Right Thing (based on your viewpoint
I just wasted a day designing a solution which seems to work but doesn't and
testing it on a variety of setups) and save the frustration you seems to have
with the newbies.

 In a nutshell, cool down and do a brain dump as some proper documentation
on the Fedora Java Packaging page (or linked to it)

 It will make you and everyone else happier !

   Thanks in advance !

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Daniel Veillard]

On Wed, Jul 02, 2008 at 12:24:02PM -0400, David Walluck wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Daniel Veillard wrote:
>  | And outside of the distro build the macros are not available and that's
>  | where the user selection should be done, so this doesn't help much in the
>  | case of a manual user rpmbuild, except maybe if one uses them to override
>  | the alternative default.
>  
>  To my knowledge they are available. At least allow the user to set
>  JAVA_HOME. This is much cleaner than a hack on following that has been
>  proven not to work ever since IBM JDK 1.4.
>  
>  |   I guess I need to think a bit more about it, but i'm firmly in the camp
>  | of those who think the package should be distribution agnostic as much as
>  | possible.
>  
>  It is distribution agnostic. Were the 6+ RPM-based distributions I
>  mentioned in a previous email not agnostic enough? Even Debian/Ubuntu
>  follow the same layout for JVM's.
>  
>  But you were speaking of an RPM build, so that covers ever major RPM
>  distro I know of.
>  
>  And if you allow $JAVA_HOME and --with-java-home= as a configure option,
>  and try /usr/lib/jvm/java first if none is specficed, then you will also
>  support Ubuntu out of the box without resorting to a hack. 
  Ah, finally some informations which may help save the problem in a
generic fashion.

So is the following looks the Right Way to package JNI code for you ?

in configure.in/ac:

- use the $JAVA_HOME as the user provided environment variable to point to
  the top of the JDK tree
- in configure.in provide an option --with-java-home allowing to override it
- if still not defined try with /usr/lib/jvm/java
- then check that $JAVA_HOME/bin contains the binaries for
  javah/javac/javah/javadoc/jar to be used when building the binaries
- then look under $JAVA_HOME/include and $JAVA_HOME/include/$system for
  the JNI includes

in the spec file:

this is still unclear but I guess

- we should look for the %{java_home} macro
- if found it should be passed as the --with-java-home value when running
  configure
- keep
  Requires: java [ >= 1.5 ]
  Requires: jpackage-utils
  and
  BuildRequires: java-devel [ >= 1.5 ]
  BuildRequires: jpackage-utils
  as the Java RPM dependancies

- Indicates that when rebuilding manually, overriding %{java_home} on the
  rpmbuild command line allows to pick a different JDK

Can you confirm those instructions ? 

If yes can this be written directly somewhere in 
  http://fedoraproject.org/wiki/Packaging/Java#Specfile_Template
in a "configure" section along ant/maven

   thanks,

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[David Walluck]

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

Daniel Veillard wrote:
| On Wed, Jul 02, 2008 at 12:27:51PM -0400, David Walluck wrote:
|> I thought Mary Ellen's email was to demonstrate how this method was bad,
|> but you took this as a reason to adaopt it. Unless you think
|> /usr/bin/ecj is not a valid Java compiler, then it's the method that's
|> broken, not the compiler location.
|
|   Why would I think ecj is not a valid Java compiler ? Stop assuming
| the only problem with ecj was that it needed the -source 1.5 flags.

My answer was not meant to be in response to the compilation problem,
but the idea of assuming that following symlinks will eventually lead
you to a valid JAVA_HOME directory. While this may be fixed to work in
Fedora, I had doubt that this could work in general (or at least that it
is the best/easiest solution).

So, this is partly where the communication was lost: I was talking
(ranting---or whatever you choose to see it as) about the
packaging/configure issues and not the problems with the compilation.

But if `-source 1.5' needs to be passed for ecj (since it defaults to
1.6), then I think it makes sense to pass it as JAVACFLAGS (or whatever
you want to call them) to every compiler, but I don't even remember now
what the exact issue was.

|  1/ I needed a way to give the user the flexibility for the JDK used

I think you could do the following. You have

BuildRequires: jpackage-utils
BuildRequires: java-devel >= 1.5.0

this means %{java_home} is defined, so in the spec you may just do

%{configure} --with-java-home=%{java_home}

Then a user would be expected to override the default value by setting
JAVA_HOME.

Alternatively, you could just look for $JAVA_HOME being set, then in the
spec you could do:

JAVA_HOME=%{java_home} %{configure}

Note that the %{java_home} macro as it's defined should honor the
$JAVA_HOME setting in the shell.

|  2/ I needed the include paths for the JNI headers

You can use ${JAVA_HOME}/include or %{java_home}/include by default.

|  3/ I needed a -source 1.5 options when compiling against the Eclipse
compiler
|     (thanks a lot Mary for the solution !)

Depending on the issue you may want this in general. If you do a
specific check for ecj, then you can't really assume the JAVA_HOME
layout which is saving you the work of writing some custom scripts for
each compiler

| Your answer as I understood it was:
|   - that I should ignore 1/

No, just that the issue was already solved.

|   - that there were some RPM macros (undefined, just a list of macro
names)

I thought the macros were self-exaplanatory, but the basic point of
their usage would be if you want to do something like

%{configure} --with-java=%{java}

vs.

%{configure} --with-java=%{java_home}/bin/java

| people should do when packaging JNI related sources (including answers to
| at least 1/ and 2/) both for configure.in and for the spec file, with
| examples and explanations of what the various macro do. You will save
a lot

I think that currently the Fedora Java Packaging Guidelines do not
discuss issues related to Java and C much if at all.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhskmsACgkQItObMyg2XCU42gCfXIpD+QHo/PYlYP1ACiIf71kK
> aygAoKco5eNP02f7hiLsvqhbQFvUXEca
> =gvhG
> -----END PGP SIGNATURE-----

[David Walluck]

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

Daniel Veillard wrote:
| - use the $JAVA_HOME as the user provided environment variable to point to
|   the top of the JDK tree
| - in configure.in provide an option --with-java-home allowing to
override it
| - if still not defined try with /usr/lib/jvm/java

Sounds good so far. You may also want to try other values for JAVA_HOME.
I don't have an exhaustive list of these, but /usr/lib/jvm/java should
be fine for any Linux distro that has jpackage-utils, so I think that
should be sufficient.

| - then check that $JAVA_HOME/bin contains the binaries for
|   javah/javac/javah/javadoc/jar to be used when building the binaries
| - then look under $JAVA_HOME/include and $JAVA_HOME/include/$system for
|   the JNI includes

I think you want something like

CPPFLAGS="-I$JAVA_HOME/include -I$JAVA_HOME/include/linux".

But if it's not linux, I don't know how standard the existence of
$system is.

| - we should look for the %{java_home} macro

This is only good for the RPM build. If you depend on jpackage-utils you
may assume it is defined.

| - if found it should be passed as the --with-java-home value when running
|   configure

In the RPM-build case, you can pass explicitly the default (or desired)
Java home directory .

You have already laid out the three basic steps for configure above:

1.) Use --with-java-home if set.

2.) If this isn't set, then you would read $JAVA_HOME from the environment.

3.) If that isn't set then you would check some pre-defined list of
directories. At the very least /usr/lib/jvm/java.

| - keep
|   Requires: java [ >= 1.5 ]
|   Requires: jpackage-utils
|   and
|   BuildRequires: java-devel [ >= 1.5 ]
|   BuildRequires: jpackage-utils
|   as the Java RPM dependancies

Yes, since these are virtual provides specified by several vendors (GCJ,
IBM, BEA, Sun) as long as they follow the JPackage standard.

| - Indicates that when rebuilding manually, overriding %{java_home} on the
|   rpmbuild command line allows to pick a different JDK

The switch happens for the end-user of the RPM spec file simply by
redefining %java_home, e.g.

rpmbuild --define 'java_home /usr/lib/jvm/java-gcj'

or

JAVA_HOME=/usr/lib/jvm/java-gcj rpmbuild

| If yes can this be written directly somewhere in
|   http://fedoraproject.org/wiki/Packaging/Java#Specfile_Template
| in a "configure" section along ant/maven

it's hard to say how to standardize this process, since no one has
written the canonical set of autoconf macros for this. Some macros exist
in the autoconf macro archive, but they try to support many layouts (not
just the linux standard layout).

Sure, we can try to specify what a call to configure would look like and
have each author write his own code to do it. A better approach might be
to write a set of canonical m4 code that might be used to satisfy those
requirements.

Minimally all that is required is to read the value of $JAVA_HOME since
you can assume a monolithic layout for the rest of the binaries and
directories used for building.

- --
Sincerely,

David Walluck
<david(a)zarb.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhslm8ACgkQItObMyg2XCUmVgCgjfbVRjxcJbnCJuzD2swSFtDh
> f+EAoIMKT8U9yvuw7H0Qu2oXDE7Wv42N
> =2H0n
> -----END PGP SIGNATURE-----

[Daniel Veillard]

On Thu, Jul 03, 2008 at 04:48:43AM -0400, David Walluck wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Daniel Veillard wrote:
>  | On Wed, Jul 02, 2008 at 12:27:51PM -0400, David Walluck wrote:
>  |> I thought Mary Ellen's email was to demonstrate how this method was bad,
>  |> but you took this as a reason to adaopt it. Unless you think
>  |> /usr/bin/ecj is not a valid Java compiler, then it's the method that's
>  |> broken, not the compiler location.
>  |
>  |   Why would I think ecj is not a valid Java compiler ? Stop assuming
>  | the only problem with ecj was that it needed the -source 1.5 flags.
>  
>  My answer was not meant to be in response to the compilation problem,
>  but the idea of assuming that following symlinks will eventually lead
>  you to a valid JAVA_HOME directory. While this may be fixed to work in
>  Fedora, I had doubt that this could work in general (or at least that it
>  is the best/easiest solution). 
  Okay. For not being the easiest, that's not surprizing !

>  So, this is partly where the communication was lost: I was talking
>  (ranting---or whatever you choose to see it as) about the
>  packaging/configure issues and not the problems with the compilation.
>  
>  But if `-source 1.5' needs to be passed for ecj (since it defaults to
>  1.6), then I think it makes sense to pass it as JAVACFLAGS (or whatever
>  you want to call them) to every compiler, but I don't even remember now
>  what the exact issue was. 
  The problem was that Mary had to guess `-source 1.5' was the problem
(since there was a BuildRequires: java-devel >= 1.5 at least from a packaging
POV this should not have happened) and also being sure that adding this
flag won't break in other environment. Since it seems to be a generic
javac flag maybe that can be passed down every time:
  http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html#options

  I had a javac command failing because of wrong args so I need to recheck
it wasn't -source

>  |  1/ I needed a way to give the user the flexibility for the JDK
> used
>  
>  I think you could do the following. You have
>  
>  BuildRequires: jpackage-utils
>  BuildRequires: java-devel >= 1.5.0
>  
>  this means %{java_home} is defined, so in the spec you may just do
>  
>  %{configure} --with-java-home=%{java_home}
>  
>  Then a user would be expected to override the default value by setting
>  JAVA_HOME.
>  
>  Alternatively, you could just look for $JAVA_HOME being set, then in the
>  spec you could do:
>  
>  JAVA_HOME=%{java_home} %{configure}
>  
>  Note that the %{java_home} macro as it's defined should honor the
>  $JAVA_HOME setting in the shell. 
  okay, so it seems you confirm the information in the previous mail

>  |  2/ I needed the include paths for the JNI headers
>  
>  You can use ${JAVA_HOME}/include or %{java_home}/include by default. 
  well it also need %{java_home}/include/$system, or wherever jni_md.h
may be needed and it's often in a subdir (or sometime not available like 
in java-1.5.0-ibm-devel-1.5.0.7-1jpp.2.el4

>  |  3/ I needed a -source 1.5 options when compiling against the
> Eclipse
>  compiler
>  |     (thanks a lot Mary for the solution !)
>  
>  Depending on the issue you may want this in general. If you do a
>  specific check for ecj, then you can't really assume the JAVA_HOME
>  layout which is saving you the work of writing some custom scripts for
>  each compiler 
  I used the following:

JAVAC_FLAGS=
javac_version=`$JAVAC -version 2>&1`
case "$javac_version" in
    *Eclipse*)
        JAVAC_FLAGS="-source 1.5"
        ;;
esac

 that seems to work fine in practice.

>  | people should do when packaging JNI related sources (including
> answers to
>  | at least 1/ and 2/) both for configure.in and for the spec file, with
>  | examples and explanations of what the various macro do. You will save
>  a lot
>  
>  I think that currently the Fedora Java Packaging Guidelines do not
>  discuss issues related to Java and C much if at all. 
  yes and IMHO that's part of the wall between Java and other communities
that we need to bring down. JNI makes it especially hard, maybe JNA will
lower the barrier, still we need to make things easier to reuse each-other
code.

  thanks !

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Daniel Veillard]

On Thu, Jul 03, 2008 at 05:05:52AM -0400, David Walluck wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Daniel Veillard wrote:
>  | - use the $JAVA_HOME as the user provided environment variable to point to
>  |   the top of the JDK tree
>  | - in configure.in provide an option --with-java-home allowing to
>  override it
>  | - if still not defined try with /usr/lib/jvm/java
>  
>  Sounds good so far. You may also want to try other values for JAVA_HOME.
>  I don't have an exhaustive list of these, but /usr/lib/jvm/java should
>  be fine for any Linux distro that has jpackage-utils, so I think that
>  should be sufficient. 
  It seems to be here, back up to RHEL4, so from my own set of systems
this looks fine.

>  | - then check that $JAVA_HOME/bin contains the binaries for
>  |   javah/javac/javah/javadoc/jar to be used when building the binaries
>  | - then look under $JAVA_HOME/include and $JAVA_HOME/include/$system for
>  |   the JNI includes
>  
>  I think you want something like
>  
>  CPPFLAGS="-I$JAVA_HOME/include -I$JAVA_HOME/include/linux".
>  
>  But if it's not linux, I don't know how standard the existence of
>  $system is. 
 yeah it's a bit painful, but I prefer not hardcode the system, for example
libvirt is used in Solaris and can compile on Windows, and examples on the
sun documentations seems to imply $system being respectively solaris and
windows on those platforms.

I used 

------------------
case "$build_os" in
    *linux*)
        system="linux"
        ;;
    *)
        system="$build_os"
        ;;
esac

if test -f $SDK/include/$system/jni_md.h ; then
    JNI_CFLAGS="$JNI_CFLAGS -I$SDK/include/$system"
else
if test "`find $SDK -name jni_md.h`" != "" ; then
    head=`find $SDK -name jni_md.h | tail -1`
    dir=`dirname $head`
    JNI_CFLAGS="$JNI_CFLAGS -I$dir"
fi
fi
------------------

  I think if you substitute SDK by JAVA_HOME you should get something
in line with the expectations, while being portable (and extensible)

>  | - we should look for the %{java_home} macro
>  
>  This is only good for the RPM build. If you depend on jpackage-utils you
>  may assume it is defined. 
  okay 

>  | - if found it should be passed as the --with-java-home value when
> running
>  |   configure
>  
>  In the RPM-build case, you can pass explicitly the default (or desired)
>  Java home directory .
>  
>  You have already laid out the three basic steps for configure above:
>  
>  1.) Use --with-java-home if set.
>  
>  2.) If this isn't set, then you would read $JAVA_HOME from the environment.
>  
>  3.) If that isn't set then you would check some pre-defined list of
>  directories. At the very least /usr/lib/jvm/java. 
  okay

>  | - keep
>  |   Requires: java [ >= 1.5 ]
>  |   Requires: jpackage-utils
>  |   and
>  |   BuildRequires: java-devel [ >= 1.5 ]
>  |   BuildRequires: jpackage-utils
>  |   as the Java RPM dependancies
>  
>  Yes, since these are virtual provides specified by several vendors (GCJ,
>  IBM, BEA, Sun) as long as they follow the JPackage standard. 
  I found that to be true even on ancient systems, which was my main worry
about a jpackage-utils dependancy, so this is fine (and that part is well
documented already)

>  | - Indicates that when rebuilding manually, overriding %{java_home}
> on the
>  |   rpmbuild command line allows to pick a different JDK
>  
>  The switch happens for the end-user of the RPM spec file simply by
>  redefining %java_home, e.g.
>  
>  rpmbuild --define 'java_home /usr/lib/jvm/java-gcj'
>  
>  or
>  
>  JAVA_HOME=/usr/lib/jvm/java-gcj rpmbuild 
  makes sense.

>  | If yes can this be written directly somewhere in
>  |   http://fedoraproject.org/wiki/Packaging/Java#Specfile_Template
>  | in a "configure" section along ant/maven
>  
>  it's hard to say how to standardize this process, since no one has
>  written the canonical set of autoconf macros for this. Some macros exist
>  in the autoconf macro archive, but they try to support many layouts (not
>  just the linux standard layout).
>  
>  Sure, we can try to specify what a call to configure would look like and
>  have each author write his own code to do it. A better approach might be
>  to write a set of canonical m4 code that might be used to satisfy those
>  requirements. 
  my experiance with auto* is that the first person who write the macros
put them in the configure.in, and they get copied/modified over by 
everybody else because cut'npaste is the simpler solution and doesn't 
add any dependancy on the version of autoconf/automake being used. It's
a bit sad, it's a bit of a mess, but works somehow.

>  Minimally all that is required is to read the value of $JAVA_HOME
> since
>  you can assume a monolithic layout for the rest of the binaries and
>  directories used for building. 
  Okay I now have a clearer idea, validated with your expertise :-)
Now, that's progress, once I have something which seems to work correctly
I will resubmit for Fedora review, and try to expose the steps,

  thanks a lot !

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Benjamin Reed]

David Walluck wrote:
>  Daniel Veillard wrote:
>  | - use the $JAVA_HOME as the user provided environment variable to 
>  point to
>  |   the top of the JDK tree
>  | - in configure.in provide an option --with-java-home allowing to
>  override it
>  | - if still not defined try with /usr/lib/jvm/java
>  
>  Sounds good so far. You may also want to try other values for JAVA_HOME.
>  I don't have an exhaustive list of these, but /usr/lib/jvm/java should
>  be fine for any Linux distro that has jpackage-utils, so I think that
>  should be sufficient.
>  
>  | - then check that $JAVA_HOME/bin contains the binaries for
>  |   javah/javac/javah/javadoc/jar to be used when building the binaries
>  | - then look under $JAVA_HOME/include and $JAVA_HOME/include/$system for
>  |   the JNI includes
>  
>  I think you want something like
>  
>  CPPFLAGS="-I$JAVA_HOME/include -I$JAVA_HOME/include/linux".
>  
>  But if it's not linux, I don't know how standard the existence of
>  $system is.
>  
>  | - we should look for the %{java_home} macro
>  
>  This is only good for the RPM build. If you depend on jpackage-utils you
>  may assume it is defined.
>  
>  | - if found it should be passed as the --with-java-home value when running
>  |   configure
>  
>  In the RPM-build case, you can pass explicitly the default (or desired)
>  Java home directory .
>  
>  You have already laid out the three basic steps for configure above:
>  
>  1.) Use --with-java-home if set.
>  
>  2.) If this isn't set, then you would read $JAVA_HOME from the environment.
>  
>  3.) If that isn't set then you would check some pre-defined list of
>  directories. At the very least /usr/lib/jvm/java.
>  
>  | - keep
>  |   Requires: java [ >= 1.5 ]
>  |   Requires: jpackage-utils
>  |   and
>  |   BuildRequires: java-devel [ >= 1.5 ]
>  |   BuildRequires: jpackage-utils
>  |   as the Java RPM dependancies
>  
>  Yes, since these are virtual provides specified by several vendors (GCJ,
>  IBM, BEA, Sun) as long as they follow the JPackage standard.
>  
>  | - Indicates that when rebuilding manually, overriding %{java_home} on the
>  |   rpmbuild command line allows to pick a different JDK
>  
>  The switch happens for the end-user of the RPM spec file simply by
>  redefining %java_home, e.g.
>  
>  rpmbuild --define 'java_home /usr/lib/jvm/java-gcj'
>  
>  or
>  
>  JAVA_HOME=/usr/lib/jvm/java-gcj rpmbuild
>  
>  | If yes can this be written directly somewhere in
>  |   http://fedoraproject.org/wiki/Packaging/Java#Specfile_Template
>  | in a "configure" section along ant/maven
>  
>  it's hard to say how to standardize this process, since no one has
>  written the canonical set of autoconf macros for this. Some macros exist
>  in the autoconf macro archive, but they try to support many layouts (not
>  just the linux standard layout). 
We have some autoconf macros that seem to work reasonably well (they've 
been tested on various linuxes, 32- and 64-bit, as well as solaris and 
macosx).

They could probably use some tweaking, but would be a start:

http://opennms.svn.sourceforge.net/svnroot/opennms/autotools/trunk/java.m4

I just noticed we're bad people, and don't have any copyright/license 
info on it, I'd be happy to make them whatever license makes them easy 
on everyone.  =)

To use it, we do:

ONMS_CHECK_JDK([1.4])
AC_CHECK_HEADER([jni.h], [], [AC_MSG_ERROR([cannot find jni.h header])])

...and in the .am:

lib_LTLIBRARIES = libjrrd.la
libjrrd_la_SOURCES = rrd_jinterface.c
libjrrd_la_LDFLAGS = -module -avoid-version $(JAVA_SHREXT_COMMAND)

.java.class:
	-mkdir -p $(classdir)
	$(JAVAC) $(JAVACFLAGS) -d $(classdir) $<


Haven't figured out a nice way to to javah stuff though, still very manual:

rrd_jinterface.c: org_opennms_netmgt_rrd_rrdtool_Interface.h

org_opennms_netmgt_rrd_rrdtool_Interface.h: 
org/opennms/netmgt/rrd/rrdtool/Interface.class
	$(JAVAH) -classpath $(classdir) org.opennms.netmgt.rrd.rrdtool.Interface

Does that help?  It's still a little opennms-specific right now, I 
think, but would be a place to start.

-- 
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/