Dear Java packaging experts, :-)

I'm trying to package ProjectX, a program operate on files from DVB
digital TV transmissions. It can not be included in Fedora for patent
reasons, but I'm trying to get it into Rpm Fusion, where the same
packaging rules applies.

David Timms has reviewed my package, and given many suggestions for
improvements. But none of us is experienced in packaging Java. We
would appreciate if someone more familiar with that also could have a
second look at the package, from the perspective of packaging Java in
particular. Is there anyone here who would like to do that?

Spec: ftp://ftp.uddeborg.se/pub/ProjectX/ProjectX.spec
SRPM: ftp://ftp.uddeborg.se/pub/ProjectX/ProjectX-0.90.4.00-6.20100806cvs.fc14.src.rpm

Review bugzilla: https://bugzilla.rpmfusion.org/show_bug.cgi?id=985
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Hi,

> But none of us is experienced in packaging Java.

I recommend looking at the Fedora Java packaging guidelines (you
probably already did this):

http://fedoraproject.org/wiki/Packaging:Java

> We would appreciate if someone more familiar with that also could have
> a second look at the package, from the perspective of packaging Java
> in particular. Is there anyone here who would like to do that?
>
> Spec: ftp://ftp.uddeborg.se/pub/ProjectX/ProjectX.spec

Things look fine after a cursory glance .spec. The only issues I see are:

- java{,-devel} >= 1.6 -> java{,-devel} >= 1:1.6.0
- do you really want the gcj stuff?

HTH,

Andrew
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Andrew Overholt:
> I recommend looking at the Fedora Java packaging guidelines (you
> probably already did this):

Yes. I learned how to do the wrapper script using jpackage utilites
from that page, for example. Though it was a while ago, and there has
been a number of changes to my package, so I reviewed the page again
now.

> - do you really want the gcj stuff?

Well, that is a good example where I would appreciate advice from
someone more experienced in Java packaging.

Originally I didn't have any GCJ support. I didn't see any need. But
then David pointed out that
http://fedoraproject.org/wiki/Packaging/GCJGuidelines says that

GCJ AOT bits SHOULD be built and included in packages.

"SHOULD" (assuming RFC 2119 interpretation) is pretty strong. So I
followed the instructions on the page and added the support.

But then in comment 20
(https://bugzilla.rpmfusion.org/show_bug.cgi?id=985#c20) Chen Lei says
that many Java packages have dropped GCJ support. And now you ask if
I want it.

I get the impression that the Wiki doesn't really reflect current
practice. Is that a correct understanding? Is GCJ support to be
considered optional nowdays, or maybe even deprecated?
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

On 08/09/2010 10:11 PM, Göran Uddeborg wrote:
> Andrew Overholt:
>> I recommend looking at the Fedora Java packaging guidelines (you
>> probably already did this):
>
> Yes. I learned how to do the wrapper script using jpackage utilites
> from that page, for example. Though it was a while ago, and there has
> been a number of changes to my package, so I reviewed the page again
> now.
>
>> - do you really want the gcj stuff?
>
> Well, that is a good example where I would appreciate advice from
> someone more experienced in Java packaging.
>
> Originally I didn't have any GCJ support. I didn't see any need. But
> then David pointed out that
> http://fedoraproject.org/wiki/Packaging/GCJGuidelines says that
>
> GCJ AOT bits SHOULD be built and included in packages.
>
> "SHOULD" (assuming RFC 2119 interpretation) is pretty strong. So I
> followed the instructions on the page and added the support.
>
> But then in comment 20
> (https://bugzilla.rpmfusion.org/show_bug.cgi?id=985#c20) Chen Lei says
> that many Java packages have dropped GCJ support. And now you ask if
> I want it.
>
> I get the impression that the Wiki doesn't really reflect current
> practice. Is that a correct understanding? Is GCJ support to be
> considered optional nowdays, or maybe even deprecated?

It's not yet officially deprecated. We argued a lot about that
wording, and came up with what you see. Perhaps the best way to put
it is "nice to have, but not compulsory." The situation is changing
continuously, with Power PC no longer a pimary architecture, but ARM
increasing importance.

The sensible rule everyone seems to use is that if adding gcj support
doesn't require much effort, add it. If not, don't.

Andrew.
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

> On 08/09/2010 10:11 PM, Göran Uddeborg wrote:
> > Andrew Overholt:
> >> I recommend looking at the Fedora Java packaging guidelines (you
> >
> >> probably already did this):
> > Yes. I learned how to do the wrapper script using jpackage utilites
> > from that page, for example. Though it was a while ago, and there has
> > been a number of changes to my package, so I reviewed the page again
> > now.
> >
> >> - do you really want the gcj stuff?
> >
> > Well, that is a good example where I would appreciate advice from
> > someone more experienced in Java packaging.
> >
> > Originally I didn't have any GCJ support. I didn't see any need. But
> > then David pointed out that
> > http://fedoraproject.org/wiki/Packaging/GCJGuidelines says that
> >
> > GCJ AOT bits SHOULD be built and included in packages.
> >
> > "SHOULD" (assuming RFC 2119 interpretation) is pretty strong. So I
> > followed the instructions on the page and added the support.
> >
> > But then in comment 20
> > (https://bugzilla.rpmfusion.org/show_bug.cgi?id=985#c20) Chen Lei says
> > that many Java packages have dropped GCJ support. And now you ask if
> > I want it.
> >
> > I get the impression that the Wiki doesn't really reflect current
> > practice. Is that a correct understanding? Is GCJ support to be
> > considered optional nowdays, or maybe even deprecated?
>
> It's not yet officially deprecated. We argued a lot about that
> wording, and came up with what you see. Perhaps the best way to put
> it is "nice to have, but not compulsory." The situation is changing
> continuously, with Power PC no longer a pimary architecture, but ARM
> increasing importance.
>
> The sensible rule everyone seems to use is that if adding gcj support
> doesn't require much effort, add it. If not, don't.
>
> Andrew.

As gcj is at 1.5 JVM level there is no point in having gcj support for
packages that require Java 1.6.

Alex

> --
> java-devel mailing list
> java-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

On 08/10/2010 11:10 AM, Alexander Kurtakov wrote:
>>
>> The sensible rule everyone seems to use is that if adding gcj support
>> doesn't require much effort, add it. If not, don't.
>
> As gcj is at 1.5 JVM level there is no point in having gcj support for
> packages that require Java 1.6.

Yes, obviously. I don't quite understand the point you're making,
though: clearly if a package requires 1.6 then adding gcj support
requires much effort, so don't add it.

Andrew.

--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Andrew Haley:
> On 08/10/2010 11:10 AM, Alexander Kurtakov wrote:
> >>
> >> The sensible rule everyone seems to use is that if adding gcj support
> >> doesn't require much effort, add it. If not, don't.
> >
> > As gcj is at 1.5 JVM level there is no point in having gcj support for
> > packages that require Java 1.6.
>
> Yes, obviously. I don't quite understand the point you're making,
> though: clearly if a package requires 1.6 then adding gcj support
> requires much effort, so don't add it.

The source code does not require 1.6. According to the documentation
of the package, 1.2.2 is enough. (I haven't tried anything less than
1.5.)

Originally I had 1.2.2 as a build requirement. When doing a build in
a minimal environment, like mock, that requirement is met by the GCJ
compiler. Compiling with the GCJ javac caused very many warnings,
though, as my reviewer pointed out. The 1.6.0 javac didn't give all
those warnings.

So the reason there is a requirement of 1.6.0 (to be changed to
1:1.6.0) in there is to enforce that compiler to be used for
compilation, from .java to .class. GCJ then, as I understand it,
takes the .jar files and makes .so files from them. And that seems to
work fine with .jar files made with 1.6.0.

But maybe I'm doing things wrong here? Is there a better way to make
sure the compilation is done with 1.6.0? Or shouldn't I do that at
all?
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

On 12:32 Tue 10 Aug , Göran Uddeborg wrote:
> Andrew Haley:
> > On 08/10/2010 11:10 AM, Alexander Kurtakov wrote:
> > >>
> > >> The sensible rule everyone seems to use is that if adding gcj support
> > >> doesn't require much effort, add it. If not, don't.
> > >
> > > As gcj is at 1.5 JVM level there is no point in having gcj support for
> > > packages that require Java 1.6.
> >
> > Yes, obviously. I don't quite understand the point you're making,
> > though: clearly if a package requires 1.6 then adding gcj support
> > requires much effort, so don't add it.
>
> The source code does not require 1.6. According to the documentation
> of the package, 1.2.2 is enough. (I haven't tried anything less than
> 1.5.)
>
> Originally I had 1.2.2 as a build requirement. When doing a build in
> a minimal environment, like mock, that requirement is met by the GCJ
> compiler. Compiling with the GCJ javac caused very many warnings,
> though, as my reviewer pointed out. The 1.6.0 javac didn't give all
> those warnings.
>

Warnings or errors? gcj uses ecj under the hood, which is more
verbose by default (more equivalent to javac -Xlint:all). The OpenJDK
source code produces ~10k warnings when compiled this way but still
works. In particular, it warns about generics usage and deprecation
on a per-use basis, whereas javac gives a single warning by default.
It even moans about unused import statements.

Sadly, one problem with gcj is the documentation seems to be very
outdated and so I'm not sure how the options to modify this (such
as -nowarn) are translated to its command-line options.

> So the reason there is a requirement of 1.6.0 (to be changed to
> 1:1.6.0) in there is to enforce that compiler to be used for
> compilation, from .java to .class. GCJ then, as I understand it,
> takes the .jar files and makes .so files from them. And that seems to
> work fine with .jar files made with 1.6.0.
>
> But maybe I'm doing things wrong here? Is there a better way to make
> sure the compilation is done with 1.6.0? Or shouldn't I do that at
> all?
> --
> java-devel mailing list
> java-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel

--
Andrew

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

On 08/10/2010 12:08 PM, Dr Andrew John Hughes wrote:
> On 12:32 Tue 10 Aug , Göran Uddeborg wrote:
>> Andrew Haley:
>>> On 08/10/2010 11:10 AM, Alexander Kurtakov wrote:
>>>>>
>>>>> The sensible rule everyone seems to use is that if adding gcj support
>>>>> doesn't require much effort, add it. If not, don't.
>>>>
>>>> As gcj is at 1.5 JVM level there is no point in having gcj support for
>>>> packages that require Java 1.6.
>>>
>>> Yes, obviously. I don't quite understand the point you're making,
>>> though: clearly if a package requires 1.6 then adding gcj support
>>> requires much effort, so don't add it.
>>
>> The source code does not require 1.6. According to the documentation
>> of the package, 1.2.2 is enough. (I haven't tried anything less than
>> 1.5.)
>>
>> Originally I had 1.2.2 as a build requirement. When doing a build in
>> a minimal environment, like mock, that requirement is met by the GCJ
>> compiler. Compiling with the GCJ javac caused very many warnings,
>> though, as my reviewer pointed out. The 1.6.0 javac didn't give all
>> those warnings.
>
> Warnings or errors? gcj uses ecj under the hood, which is more
> verbose by default (more equivalent to javac -Xlint:all). The OpenJDK
> source code produces ~10k warnings when compiled this way but still
> works. In particular, it warns about generics usage and deprecation
> on a per-use basis, whereas javac gives a single warning by default.
> It even moans about unused import statements.

Indeed. It's interesting that all this pointless bellyaching ecj
does makes people think something has gone wrong.

Andrew.
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Dr Andrew John Hughes:
> Warnings or errors? gcj uses ecj under the hood, which is more
> verbose by default

Warnings. Indeed, mostly about generics, and some odd unused
variables. If it is safe to ignore them, I could do that.

I don't loose anything else in using the GCJ rather than OpenJDK
compiler? Does the quality of the code produced differ in any
relevant way, or so?
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel