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
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.
[ oops, just replied to Andrew the first time ... ]
2008/7/1 Andrew Haley aph@redhat.com:
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 wrote:
[ oops, just replied to Andrew the first time ... ]
2008/7/1 Andrew Haley aph@redhat.com:
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.
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@redhat.com:
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
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...)
-----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@zarb.org
2008/7/1 David Walluck david@zarb.org:
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
-----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@zarb.org
2008/7/1 David Walluck david@zarb.org:
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 wrote:
2008/7/1 David Walluck david@zarb.org:
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.
2008/7/2 Andrew Haley aph@redhat.com:
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
2008/7/2 Mary Ellen Foster foster@in.tum.de:
2008/7/2 Andrew Haley aph@redhat.com:
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 wrote:
2008/7/2 Mary Ellen Foster foster@in.tum.de:
2008/7/2 Andrew Haley aph@redhat.com:
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.
On Wed, Jul 02, 2008 at 11:30:09AM +0100, Andrew Haley wrote:
Mary Ellen Foster wrote:
2008/7/1 David Walluck david@zarb.org:
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
-----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@zarb.org
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
-----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@zarb.org
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
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. =)
-----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@zarb.org
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.
-----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@zarb.org
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
-----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@zarb.org
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
-----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@zarb.org
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
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.
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.
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
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
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
java-devel@lists.fedoraproject.org