Bug 172320 - FSF JRE location wrong?
FSF JRE location wrong?
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-02 14:30 EST by Anthony Green
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-02 14:39:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anthony Green 2005-11-02 14:30:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.0.6-1.2.fc4 Firefox/1.0.6

Description of problem:
The "Java" page of the Options dialog lists the FSF JRE, which is nice - but the "Location" at the bottom of the dialog says "/usr".

/usr/java, /usr/javac, etc are symlinks controlled by alternatives, so they may point to any number of JRE implementations.  Could things get messed up if someone were to switch to a Sun alternative via "alternatives --config java"?

I don't know if this "Location" is used for anything significant.  If it is, perhaps it would be best to refer to /usr/lib/jvm/java-1.4.2-gcj, which is the equivalent of JAVA_HOME for the gcj-based JRE.


Version-Release number of selected component (if applicable):
openoffice.org-core-2.0.0-3.2.1

How reproducible:
Always

Steps to Reproduce:
1.Go to the Java page of the Options dialog, and look at the Location of the FSF JRE

  

Additional info:
Comment 1 Caolan McNamara 2005-11-02 14:39:44 EST
no it's right. it's the dir above the bin directory in which the "true"
executable for the given jre was found, i.e. /usr from /usr/bin/gij
Comment 2 Anthony Green 2005-11-02 14:54:12 EST
(In reply to comment #1)
> no it's right. it's the dir above the bin directory in which the "true"
> executable for the given jre was found, i.e. /usr from /usr/bin/gij

Yes, I realize that.   /usr/lib/jvm/java-1.4.2-gcj/bin/java exists and will
always symlink to gij.

But now I'm guessing that you're searching for gij, so I suppose what you're
doing will always work as well.

However, if OO.o always searches under /usr/lib/jvm it should find all of the
installed JRE's and never have to special case gij.

Running "alternatives --display java  | grep priority" might even be a better way.



Comment 3 Caolan McNamara 2005-11-03 02:56:46 EST
Only for systems that use jpackage and alternatives, it's the same code for
solaris, windows, yada, yada. the gory search system is in
OOO680_m3/jvmfwk/plugins/sunmajor/pluginlib. The gcj stuff is just one tiny
subset of the full search thingy. Maybe there's an argument to add support for
using alternatives when supported, I'll suggest it to the jvmfwk people.

Note You need to log in before you can comment on or make changes to this bug.