FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development Java

 
 
LinkBack Thread Tools
 
Old 07-02-2008, 12:59 PM
Daniel Veillard
 
Default libvirt-java bindings

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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-02-2008, 01:37 PM
Daniel Veillard
 
Default libvirt-java bindings

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

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

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-02-2008, 02:42 PM
"Mary Ellen Foster"
 
Default libvirt-java bindings

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

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-02-2008, 02:56 PM
Andrew Haley
 
Default libvirt-java bindings

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.

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-02-2008, 04:24 PM
David Walluck
 
Default libvirt-java bindings

-----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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iEYEARECAAYFAkhrq6IACgkQItObMyg2XCXaRwCfSZSBoPkDLO RYmSElqeiVpaUP
xh8Ani1hNq8Jb55LZ8pOTbhE2gX7R58r
=A+P5
-----END PGP SIGNATURE-----

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-02-2008, 04:27 PM
David Walluck
 
Default libvirt-java bindings

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

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-03-2008, 07:03 AM
Daniel Veillard
 
Default libvirt-java bindings

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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-03-2008, 07:37 AM
Daniel Veillard
 
Default libvirt-java bindings

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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-03-2008, 08:48 AM
David Walluck
 
Default libvirt-java bindings

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

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-03-2008, 09:05 AM
David Walluck
 
Default libvirt-java bindings

-----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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iEYEARECAAYFAkhslm8ACgkQItObMyg2XCUmVgCgjfbVRjxcJb nCJuzD2swSFtDh
f+EAoIMKT8U9yvuw7H0Qu2oXDE7Wv42N
=2H0n
-----END PGP SIGNATURE-----

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 

Thread Tools




All times are GMT. The time now is 12:57 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org