Bug 145647 - The priority of gcj in alternatives is too high.
The priority of gcj in alternatives is too high.
Product: Fedora
Classification: Fedora
Component: java-1.4.2-gcj-compat (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
Depends On:
  Show dependency treegraph
Reported: 2005-01-20 08:49 EST by Ryo Dairiki
Modified: 2007-11-30 17:10 EST (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description Ryo Dairiki 2005-01-20 08:49:35 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
The priority of /usr/share/java/libgcj-java-placeholder.sh in the
alternatives stands for the command "java" is 100.
This value is higher than that of sun's java which you can download
from sun's site.
The priority of sun's java is 3.

There are many people who say that they installed java from sun's
site, but that they can't run them by typing "java" in terminals.
So please decrease the priority value of gcj's java to 1 or 2.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Install libgcj-3.4.2-6.fc3
2.Install jdk-1.5.0_01-fcs which you can download from sun's site.
3.Run java from a terminal

Actual Results:  You get the output as follow:


This script is a placeholder for the /usr/bin/java
master link required by jpackage.org conventions.  libgcj's
rmiregistry, rmic and jar tools are now slave symlinks to these
masters, and are managed by the alternatives(8) system.

This change was necessary because the rmiregistry, rmic and jar tools
installed by previous versions of libgcj conflicted with symlinks
installed by jpackage.org JVM packages.
Usage: gij [OPTION] ... CLASS [ARGS] ...
          to invoke CLASS.main, or
       gij -jar [OPTION] ... JARFILE [ARGS] ...
          to execute a jar file
Try `gij --help' for more information.

Expected Results:  You get the output as follow:

Usage: java [-options] class [args...]
           (to execute a class)
   or  java [-options] -jar jarfile [args...]
           (to execute a jar file)

where options include:
    -d32          use a 32-bit data model if available

    -d64          use a 64-bit data model if available
    -client       to select the "client" VM
    -server       to select the "server" VM
    -hotspot      is a synonym for the "client" VM  [deprecated]
                  The default VM is client.

    -cp <class search path of directories and zip/jar files>
    -classpath <class search path of directories and zip/jar files>
                  A : separated list of directories, JAR archives,
                  and ZIP archives to search for class files.
                  set a system property
                  enable verbose output
    -version      print product version and exit
                  require the specified version to run
    -showversion  print product version and continue
    -jre-restrict-search | -jre-no-restrict-search
                  include/exclude user private JREs in the version search
    -? -help      print this help message
    -X            print help on non-standard options
                  enable assertions
                  disable assertions
    -esa | -enablesystemassertions
                  enable system assertions
    -dsa | -disablesystemassertions
                  disable system assertions
                  load native agent library <libname>, e.g.
                    see also, -agentlib:jdwp=help and -agentlib:hprof=help
                  load native agent library by full pathname
                  load Java programming language agent, see

Additional info:
Comment 1 Thomas Fitzsimmons 2005-03-03 18:48:11 EST
If you want to use Sun's JVM, your best bet is to build a JPackage starting from
their .nosrc.rpm.  Installing the resulting RPM will cause Sun's VM to own the
java tools in /usr/bin.  Otherwise, if you just want to use Sun's RPM, you'll
need to put $JAVA_HOME/bin at the start of your PATH.  In general, you should
put any custom binary directory at the start of your PATH to ensure that custom
binaries take precedence over system-default ones.

Note that in Fedore Core 4 test 1, you may not need Sun's JVM anymore;
java-1.4.2-gcj-compat and java-1.4.2-gcj-compat-devel wrap the GCJ toolset to
provide JPackage-compatible Free Software runtime and development environments.
 Give them a try!


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