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