Re: Update for the GCJ section of Java Guidelines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx> [2010-04-28 12:11]:
> >>>>> "AO" == Andrew Overholt <overholt@xxxxxxxxxx> 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 mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux