3:43 p.m.
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
10:59 a.m.
>>>> "AO" == Andrew Overholt
<overholt(a)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<
11:01 a.m.
Hi,
* Jason L Tibbitts III <tibbs(a)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
11:10 a.m.
>>>> "AO" == Andrew Overholt
<overholt(a)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<
11:16 a.m.
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
12:54 p.m.
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(a)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<
1:11 p.m.
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(a)math.uh.edu> [2010-04-28 12:11]:
>>>>> "AO" == Andrew Overholt
<overholt(a)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
5097
days inactive
5108
days old
packaging@lists.fedoraproject.org
7 comments
4 participants
participants (4)
-
Aleksandar Kurtakov -
Andrew Overholt -
Jason L Tibbitts III -
Patrice Dumas