I've just been looking at bug 262401 [1] to see what I need to do to update it to the new Java packaging guidelines. I have 2 new questions about the guidelines. First, the guidelines say that I must both Requires and Build-Requires jpackage-utils. This bit of code needs nothing in jpackage-utils that I can discern. It has no external dependencies, doesn't ship with any binary blobs, etc. The guidelines say must, so I'll do it, but what is the rationale?

I've just been looking at bug 262401 [1] to see what I need to do to update it to the new Java packaging guidelines. I have 2 new questions about the guidelines. First, the guidelines say that I must both Requires and Build-Requires jpackage-utils. This bit of code needs nothing in jpackage-utils that I can discern. It has no external dependencies, doesn't ship with any binary blobs, etc. The guidelines say must, so I'll do it, but what is the rationale? Second, the GCJ guidelines say, "For Fedora versions < 8, no JDK was available other than GCJ so GCJ AOT bits MUST be present." This presents a problem for the package in question, because it consists of annotations only. They are Java 1.5 annotations, so the GCJ in F7 can produce the needed class files. But there is no actual code to compile, so there is nothing for the GCJ AOT bits to do. Can an exception be granted to annotation-only packages (not that there are likely to be many of those)?

Andrew Haley wrote: > Jerry James wrote: >> I've just been looking at bug 262401 [1] to see what I need to do to >> update it to the new Java packaging guidelines. I have 2 new >> questions about the guidelines. >> >> First, the guidelines say that I must both Requires and Build-Requires >> jpackage-utils. This bit of code needs nothing in jpackage-utils that >> I can discern. It has no external dependencies, doesn't ship with any >> binary blobs, etc. The guidelines say must, so I'll do it, but what >> is the rationale? >> >> Second, the GCJ guidelines say, "For Fedora versions < 8, no JDK was >> available other than GCJ so GCJ AOT bits MUST be present." This >> presents a problem for the package in question, because it consists of >> annotations only. They are Java 1.5 annotations, so the GCJ in F7 can >> produce the needed class files. But there is no actual code to >> compile, so there is nothing for the GCJ AOT bits to do. Can an >> exception be granted to annotation-only packages (not that there are >> likely to be many of those)? > > Amazing -- I never even imagined that such a thing as an annotation-only > package might exist! The guidelines are intended to allow reasonable > people to interpret them sensibly. In this case, AOT-compiling wouldn't > hurt but wouldn't be of much benefit, so I don't think it matters. > Andrew, if you could propose some wording changes to the Guidelines for this it would be most appreciated.

On Wed, Apr 16, 2008 at 11:32 AM, Andrew Haley <aph(a)redhat.com&gt; wrote: > "In some rare cases Java packages might not contain any executable code > whatsoever, so AOT-compiling for gcj would not be required. An example > of such a package would be one that contained only annotations." Perhaps "annotation definitions" would be a bit more precise.

Amazing -- I never even imagined that such a thing as an annotation-only package might exist! The guidelines are intended to allow reasonable people to interpret them sensibly. In this case, AOT-compiling wouldn't hurt but wouldn't be of much benefit, so I don't think it matters.

On 2008-04-14, 21:35 GMT, Jerry James wrote: > Can an exception be granted to annotation-only packages (not > that there are likely to be many of those)? Or ugly solution -- wait two months ;-) Then all supported Fedoras will have JDK. No, I am not serious.

If you can find something it will run besides whatever benchmark you used for that measurement... And will OpenJDK run OpenNMS?

Do you have an estimate for the man-hours of modifications it took to make that possible to help others decide on the feasibility of using gcj instead of Sun Java in general?

On Tue, 2008-04-15 at 18:10 -0500, Les Mikesell wrote: > Do you have an estimate for the man-hours of modifications it took to > make that possible to help others decide on the feasibility of using gcj > instead of Sun Java in general? I don't, but that's a moot point because Fedora couldn't ship Sun Java. I'd like to think that a lot of the work that went into GCJ aided in the push to get Sun to open up Java so that we /could/ ship it.

Le Mer 16 avril 2008 01:12, Jesse Keating a écrit : > On Tue, 2008-04-15 at 18:10 -0500, Les Mikesell wrote: >> Do you have an estimate for the man-hours of modifications it took to >> make that possible to help others decide on the feasibility of using gcj >> instead of Sun Java in general?

> I don't, but that's a moot point because Fedora couldn't ship Sun Java. > I'd like to think that a lot of the work that went into GCJ aided in the > push to get Sun to open up Java so that we /could/ ship it. Sure, that was a good argument for pushing gcj in the past. The question is should we focus on gcj or openjdk/icedtea now.

> Sure, that was a good argument for pushing gcj in the past. > The question is should we focus on gcj or openjdk/icedtea now. IMHO the only reason Java bytecode exists is to make it possible to distribute "run anywhere" proprietary software while keeping the source code closed. Thus in an open source environment, Java bytecode has little reason to exist.

If we're going to *distribute* compiled code, it may as well be nice fast native code. Yes I know what you're going to say, lots of languages, such as Python do bytecode as well. But they do it as a backend implementation detail, with no guarantee of stability and stored on disk only as a performance optimization, rather than an intentional mechanism for source code obfuscation. IMO we, the open source community, should shun Java bytecode.

[will be eclipsed] by C# [...] in native compilation.

Callum Lerwick wrote: > The closed source > world will gladly continue cranking out Java code as it is the COBOL of > the 90+'s... I think you are missing a fairly vast library of available open source java code.

2008/4/27 Callum Lerwick <seg(a)haxxed.com&gt;: > > IMHO the only reason Java bytecode exists is to make it possible to > distribute "run anywhere" proprietary software while keeping the source > code closed. No. Even originally, that isn't true.

Having separate source and binary formats gives you a lot of flexibility; for example you can compile source code that uses new features into an older bytecode in a compatibility mode.

If you think the reason it's still around is just obfuscation, try using a modern decompiler.

> Thus in an open source environment, Java bytecode has > little reason to exist. If we're going to *distribute* compiled code, it > may as well be nice fast native code. 1) Hotspot does a fine job of creating native code.

2) There are a *ton* of languages other than Java that run on top of the JVM that compile to bytecode. JRuby, to name one.

3) It's simply not worth trying to go against the grain of the entire Java community here.

Jesse Keating wrote: > On Tue, 2008-04-15 at 17:53 -0500, Les Mikesell wrote: >> If you can find something it will run besides whatever benchmark you >> used for that measurement... And will OpenJDK run OpenNMS? > > GCJ runs Eclipse, which is a pretty important tool to a lot of people. Do you have an estimate for the man-hours of modifications it took to make that possible to help others decide on the feasibility of using gcj instead of Sun Java in general?

Lubomir Kundrak wrote: > > Why not? Getting rid of legacy cruft sounds like an brilliantly elegant > solution to me. But probably not applicable here, as GCJ doesn't really > fall into that category, given it still outperforms OpenJDK by the > factor of 10 on ppc. If you can find something it will run besides whatever benchmark you used for that measurement... And will OpenJDK run OpenNMS?

> > Or ugly solution -- wait two months ;-) Then all supported > Fedoras will have JDK. > > No, I am not serious. > Why not? Getting rid of legacy cruft sounds like an brilliantly elegant solution to me. But probably not applicable here, as GCJ doesn't really fall into that category, given it still outperforms OpenJDK by the factor of 10 on ppc.