GCJ AOT bits are mandatory parts of any Java packages according to current guidelines. There are at least 2 reasons to not require them: 1. GCJ has stagnated at Java 1.5 level and gcj bits require having GCJ installed even in cases when the package requires Java >= 1.6. Resulting in an installed but unusable for the given package JVM 2. GCJ AOT bits makes every package an arch specific one (when they are noarch in general)- resulting in slower package build, slower install/uninstall, bigger packages and etc.
There are other benefits like - much more readable RPM spec files, using less resources on Fedora infrastructure. But the main benefit is for the users - we do not have to force them to install something they will never use. E.g installing eclipse-jdt drags gcj in but upstream is not supporting it and there is even a warning added to indicate that you're running gcj and it may not work as expected but gcj is still installed because of eclipse dependencies that have the gcj bits.
This mail is by no means saying that there is no value in gcj. But gcj has a different usecases and shouldn't be thrown at every user. GCJGuidelines should be changed in such a way that they should indicate that you may add GCJ AOT bits to your package but this should not result in mandatory installation of GCJ (e.g. by making the gcj aot bits a separate subpackage auto-generated like the debug packages, but this is up to the people interested in gcj to solve). We simply don't have to force users to install a non-default and less feature full JVM in order to use our packages with another JVM.
Regards, Alexander Kurtakov
"AO" == Andrew Overholt overholt@redhat.com writes:
AO> I thought we wrote the guidelines to make them optional. I agree AO> they should definitely be made optional at this point.
The use of GCJ is currently "should" which means "unless you have a good reason not to do so". It's always been that way, and has never been interpreted by most reviewers as being optional.
I can draft up a change which changes the strength of the GCJ recommendation. However, not being familiar with Java I'm not sure if we should now be recommending against GCJ, or if it's simply a "use it if you want to" thing. Akexander's message gives several reasons why we should be telling people not to use it (or at least it seems that way to me) and given that I'm having trouble understanding why we shouldn't just be saying "you should (or even must) not compile with GCJ" at this point.
- J<
Hi,
* Jason L Tibbitts III tibbs@math.uh.edu [2010-04-28 11:59]:
I can draft up a change which changes the strength of the GCJ recommendation. However, not being familiar with Java I'm not sure if we should now be recommending against GCJ, or if it's simply a "use it if you want to" thing.
Let's make it a "use it if you want to" thing.
Thanks,
Andrew
"AO" == Andrew Overholt overholt@redhat.com writes:
AO> Let's make it a "use it if you want to" thing.
In that case, we still need to indicate some basic positives and negatives of using it, at least so that people who think "it's cool to include _everything_ in my packages" won't go ahead and do it without an understanding of the downsides.
http://fedoraproject.org/wiki/Packaging:GCJGuidelines has the current guidelines. We can obviously remove the caution box for Fedora 8 at this point, but the first two paragraphs should be rewritten.
While we're in there, could you also verify that the rest of the GCJGuidelines page are correct? Anything else you'd like to add or change in the main http://fedoraproject.org/wiki/Packaging:Java guideline page?
Finally, what might EPEL (RHEL4 and RHEL5) need to do regarding GCJ? I suppose they still need to use it, and will need an indication of that in their guidelines.
- J<
On Wed, Apr 28, 2010 at 11:10:58AM -0500, Jason L Tibbitts III wrote:
Finally, what might EPEL (RHEL4 and RHEL5) need to do regarding GCJ? I suppose they still need to use it, and will need an indication of that in their guidelines.
Unless I am missing something RHEL5 is not very different from fedora since openjdk is available.
-- Pat
Perhaps I simply missed it, but I don't believe I've seen any response to my previous message and I'd really like to get a bit of clarification before I go poking around in the guidelines without fully understanding the issue.
Also, a question came up on the devel list regarding whether javadoc packages must have a dependency on the main package, which is shown in the templates but not addressed in the guideline. If I could get an answer to that as well, I'll go ahead and draft an update.
My message from last week is included below in case it was somehow dropped by the list software.
"AO" == Andrew Overholt overholt@redhat.com writes:
AO> Let's make it a "use it if you want to" thing.
In that case, we still need to indicate some basic positives and negatives of using it, at least so that people who think "it's cool to include everything in my packages" won't go ahead and do it without an understanding of the downsides.
http://fedoraproject.org/wiki/Packaging:GCJGuidelines has the current guidelines. We can obviously remove the caution box for Fedora 8 at this point, but the first two paragraphs should be rewritten.
While we're in there, could you also verify that the rest of the GCJGuidelines page are correct? Anything else you'd like to add or change in the main http://fedoraproject.org/wiki/Packaging:Java guideline page?
Finally, what might EPEL (RHEL4 and RHEL5) need to do regarding GCJ? I suppose they still need to use it, and will need an indication of that in their guidelines.
- J<
Hi,
(Sorry for the delay; I've had this in my inbox and have been meaning to reply but you know how things go ...)
* Jason L Tibbitts III tibbs@math.uh.edu [2010-04-28 12:11]:
"AO" == Andrew Overholt overholt@redhat.com writes:
AO> Let's make it a "use it if you want to" thing.
In that case, we still need to indicate some basic positives and negatives of using it, at least so that people who think "it's cool to include _everything_ in my packages" won't go ahead and do it without an understanding of the downsides.
How about something like these?
- the class library that gcj uses does not have changes made in Java 1.6 so if your code requires these it will not compile - some upstream projects have noticed behavioural differences when their code runs with gij [ed: not a typo; gij is the runtime] versus when it runs with more traditional, just-in-time compilers like the Sun JVM. This may influence your decision about whether not you should ship GCJ AOT .sos in your package. - HotSpot, the just-in-time compiler that is part of OpenJDK, is not available on architectures other than x86, x86_64, and Sparc. While users of, for example, ppc, will likely be able to run your package's Java code with the simple Java bytecode interpreter that is present in gij, it will be noticeably [ed: I've heard orders of magnitude but it is situation-dependent] slower.
While we're in there, could you also verify that the rest of the GCJGuidelines page are correct?
I'm not sure about requesting that people file bugs anymore. Sure, it'd be _nice_ I guess but I don't (personally) think many people will still rely on the gij + gcj .so combination now that OpenJDK is available in most distros and non-x86{,_64} hardware isn't used as much as it once was (I'm sure people will disagree ...).
The repeated "1."s could be replaced with hard-coded numbers for the steps. Otherwise, things still seem applicable as written.
Anything else you'd like to add or change in the main http://fedoraproject.org/wiki/Packaging:Java guideline page?
Finally, what might EPEL (RHEL4 and RHEL5) need to do regarding GCJ?
OpenJDK is available in RHEL/EPEL 5 so the same information applies. I don't know if it's in RHEL/EPEL 4. That being said, I don't know what state of the gcj class library is in RHEL 4.
Andrew
packaging@lists.fedoraproject.org
-
Aleksandar Kurtakov -
Andrew Overholt -
Jason L Tibbitts III -
Patrice Dumas