Bug 172320

Summary: FSF JRE location wrong?
Product: [Fedora] Fedora Reporter: Anthony Green <green>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-11-02 19:39:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Anthony Green 2005-11-02 19:30:23 UTC 
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 19:39:44 UTC 
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 19:54:12 UTC 
(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 07:56:46 UTC 
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.