On Sat, 2005-08-06 at 19:08 +0000, duffmckagan wrote:

On 8/6/05, Greg Knaddison greg.knaddison@gmail.com wrote:

...

On 8/6/05, duffmckagan mckagan@gmail.com wrote:

...

java -version ......i don't get any output.

How about

# updatedb

#locate java

?

Updating the data base doesn't help. #locate java ....gives an incredible list of paths.

look in /usr/local/bin

On Sat, 2005-08-06 at 19:15 +0000, duffmckagan wrote:

It is installed in /usr/java

Be _careful_ on that. Red Hat ships a GNU Java run-time.

E.g.,

ls -la /usr/bin/java ... /usr/bin/java -> /etc/alternatives/java

ls -la /etc/alternatives/java ... /etc/alternatives/java -> /usr/lib/jvm/jre-1.4.2-gcj/bin/java ^^^

You should use the alternatives framework to change it to Sun's Java. I have never gotten this to work correctly myself, so I just change the symlink manually (not ideal).

On 8/6/05, Greg Knaddison greg.knaddison@gmail.com wrote:

On 8/6/05, duffmckagan mckagan@gmail.com wrote:

...

Updating the data base doesn't help. #locate java ....gives an incredible list of paths.

Great, so it's installed and you just need to edit your path.

If which <command> doesn't find it then look elsewhere (e.g. locate).

Regards, Greg _______________________________________________

I have already used the locate command, and no use. It gave me a lotta output. Now, I am gonna take a look at Dag's repository.

...

If all you need is the runtime environment, you can install this from dag's repository (dag.wieers.com/home-made/j2re/ install instructions for the repo at http://dag.wieers.com/home-made/apt/FAQ.php#B4 )

I found an error 404 while accessing the first link.

The first url I provided was off the top of my head, which appears to be incorrect. Sorry about that. It should have been http://dag.wieers.com/packages/j2re/

But why would I need to uninstall the existing rpm, if it is gonna work good? If it not, I will surely get it working by following dag's method.

The java rpm gives you a basic java install, but as you've already discovered, it's not immediately functional. In addition, it doesn't do much in the way of setting up a java environment for the user. Dag's rpm generates a java.desktop file which provides you with a link in menus, as well as an icon to click for java access. It sets the path appropriately, updates mime-types and provides a browser plugin which essentially gives you a warm fuzzy java runtime installation that requires almost no setup. This is why for new users, normal users and people who don't need the java development pack to use dag's packages.

Java is good software, but it's packaging is some of the worst I've seen, and is designed to be installed by administrators, not the average user. this is why dag, jpackage and others have repackaged it.

What you have installed WILL work, it just will take some configuring. I recommended dag's packaging as a way for you to get up and running quickly with a good setup, not to say that yours would not work.

Moreover, i also need to configure my yum. I have been working with apt (In Debian) a lot, and this yum is quite new to me.

In which case you'll probably want to add dag's repository anyway for things like mplayer, dvd software, xmms-mp3, and a whole host of other useful packages.

I find that with dag's repository, and the extras rebuild provided at http://centos.karan.org I can usually find nearly everything I need.

-- Jim Perrin System Administrator - UIT Ft Gordon & US Army Signal Center

On 8/7/05, duffmckagan mckagan@gmail.com wrote:

Thanks for the reply. ....that was cool. That thing made the things quite clear. I will download the package from Dag's repository tomorrow, and uninstall the one from Sun.

I need to sleep this night. See you guys tomorrow. (I am in a different time zone.)

Hello,

Below are the steps I'm using to install the Java 5 SDK that is from Sun. I hope this helps you. This has worked for me every time.

Anyway, below are the steps I did to set up the Java development environment:

1. Download the latest Java 5 SDK from http://java.sun.com (35 MB)

2. $sudo rpm -Uvh jdk-1_5_0_04-linux-i586.rpm

3. # ln -sf /usr/java/jdk1.5.0_04 /usr/local/java

We do this so that if a new Java version comes out, we can install the RPM and only change the directory that the symlink points to. It's more upgrade-friendly this way.

4. Edit /etc/profile and add the following lines:

export JAVA_HOME=/usr/local/java export CLASSPATH=.:$JAVA_HOME/jre/lib/rt.jar export PATH=$JAVA_HOME/bin:$PATH

The jikes compiler requires that the CLASSPATH be set to the correct directory. The "." entry lets us include classes which are in the same directory. The last one adds our directory to the path.

You can also opt to put these lines in your .bashrc. But I prefer it this way so that the changes are system-wide.

5. # alternatives --install /usr/bin/java java /usr/local/java/bin/java 3

The default java compiler is gcj. We use the alternatives system to install our new Java setup without overwriting the previous gcj settings. If we want to use gcj, we can easily switch to that one by running # alternatives --config java

6. # alternatives --config java (then choose our new Java command)

Choose the one that is on the /usr/local/java directory.

Matt Arnilo S. Baluyos wrote:

5. # alternatives --install /usr/bin/java java /usr/local/java/bin/java 3

Jim Perrin wrote:

This is quite a bit cleaner than I've done things in the past, and something I should probably learn.

Yeah, I've done this a few times, but ...

Matt Arnilo S. Baluyos wrote:

6. # alternatives --config java (then choose our new Java command)

Jim Perrin wrote:

After running this command, I ran alternatives --display java and noticed that a fair amount of the slaves were not set including jre etc. Have you worried about setting these? I've read through the manpage for alternatives, but if you have any other documentation sources I'd love to read them.

That's why I don't go through the whole mess. One of these days I've make an RPM to "fix" the alternatives.

But until then, I typically either do things manually, or yank the GCJ install.

On Sun, 2005-08-07 at 14:06 -0400, Jim Perrin wrote:

Okay, so that's a NO from BJS on useful information in an email reply. Does anyone else have something related to /etc/alternatives documentation to contribute? I'd very much like to learn this as it seems cleaner than my current methods.

Matt basically gave you the example command:

alternatives --install /usr/bin/java java /usr/local/java/bin/java 3

Now just re-apply the same logic to _all_ java-related files in /etc/alternatives. Hit "man 1 alternatives" when in doubt.

The alternatives framework is LSB, so it's good to know (for all LSB compliant Linux distros). I was just commenting that one of these days someone needs to generate an RPM that does this for you without getting into all the redistribution issues (i.e., don't include Sun Java in the package).**

-- Bryan

P.S. AFAICT, I was the _first_ person to catch the original poster not realizing that /usr/bin/java was GCJ (while everyone else largely ignored the CGJ issue, and gave "install blah" until Matt's latter post): http://lists.centos.org/pipermail/centos/2005-August/009470.html

**P.P.S. Java, like Perl and other development systems, is one area where "Emerge" might be a better way to do things -- both legally and technically. I.e., the ports tree could handle the administrative end, while fetching the JRE/JDK directly from Sun.

On Sun, 2005-08-07 at 14:33 -0400, Jim Perrin wrote:

Perhaps you should re-read my question. His command is what prompted my interest primarily because immediately following his command I checked the results with --display which provides interesting results. after running --config and selecting the sun java pack on my test machine, I noticed that several of the slave values were not set in either case, and the final line is what really caught my eye.

I know. But had you read the thread closer, earlier, you would have seen my mention of "alternatives." Why are you so judgmental? Just because my earlier response (and the fact that I manually maintain links in /etc/alternatives) is supposedly "less helpful" than Matt's? Why do you have to assert such?

There is no man 1 alternatives. alternatives is provided by chkconfig and only has man (8) associated with it as 'man -k alternatives' shows.

Sorry, I meant "8" (why I wrote "1" I have no idea).

Here's your cookie.

I was _not_ asking for a cookie. I was only asking that you don't pass judgment on me. It's stuff like this that keeps me from wanting to respond at all. Had Matt not made his post, then there would have been *0* mentions of GCJ/alternatives (out of over a dozen!).

From the way I see it, my earlier post was the _first_ to get to the

"core problem." Now I'm glad Matt made an even better post with an actual command, and that's what we're all here for, to help each other. But I think it's rather rude to do what you did considering I _was_ "on the mark" more than several others.

While you have provided some invaluable information to the list, we're wandering way off topic again. This has nothing to do with Matt's current(or recently past) jre install, or with my query on the alternatives framework. This is more of an RFE/implementation discussion that's moot for all current RHEL/CentOS platforms. Yes. I'm blunt, borderline arrogant, and generally antisocial, but at least I stay on topic with my hostility.

Dude, I _was_ on-topic in _several_ of my posts. Quit asserting was is on-topic and off-topic, as I can easily note several of your past posts that are prime examples of _hypocrisy_.

On Sun, Aug 07, 2005 at 05:54:16PM -0500, Jay Leafey enlightened us:

I don't know if this is much use, but here's the command I used to add the Sun JDK to alternatives after I installed the RPM (look out for line wrap):

alternatives \ --install /usr/bin/java java /usr/java/jdk1.5.0_04/jre/bin/java 10 \ --slave /usr/bin/rmiregistry rmiregistry \ /usr/java/jdk1.5.0_04/jre/bin/rmiregistry \ --slave /usr/lib/jvm/jre jre /usr/java/jdk1.5.0_04/jre

This sets all of the slaves except jre_exports, which I could not seem to find in the Sun JDK. Anybody got any ideas on what this should actually point to?

Anyway, I then used the command 'alternatives --set java /usr/java/jdk1.5.0_04/jre/bin/java' to switch over to using the Sun Java. Heres what the alternatives output looks like afterwards:

[root@jaybird ~]# alternatives --display java java - status is manual. link currently points to /usr/java/jdk1.5.0_04/jre/bin/java /usr/lib/jvm/jre-1.4.2-gcj/bin/java - priority 1420 slave rmiregistry: /usr/lib/jvm/jre-1.4.2-gcj/bin/rmiregistry slave jre_exports: /usr/lib/jvm-exports/jre-1.4.2-gcj slave jre: /usr/lib/jvm/jre-1.4.2-gcj /usr/java/jdk1.5.0_04/jre/bin/java - priority 10 slave rmiregistry: /usr/java/jdk1.5.0_04/jre/bin/rmiregistry slave jre_exports: (null) slave jre: /usr/java/jdk1.5.0_04/jre Current `best' version is /usr/lib/jvm/jre-1.4.2-gcj/bin/java. [root@jaybird ~]# java -version java version "1.5.0_04" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)

The reason the GCJ version shows up as the 'best' is because it has a higher priority (1420) than the Sun version (10). Just change the priority in the 'alternatives --install' command listed above to something higher than 1420 and the Sun version will become the 'best' version.

Just my $.02.

The jpackage.org folks take things even further. Check their spec file, but it results in:

[hyclak@euclid ~]$ /usr/sbin/alternatives --display java java - status is auto. link currently points to /usr/lib/jvm/jre-1.5.0-sun/bin/java /usr/lib/jvm/jre-1.4.2-gcj/bin/java - priority 1420 slave keytool: (null) slave orbd: (null) slave policytool: (null) slave rmid: (null) slave rmiregistry: /usr/lib/jvm/jre-1.4.2-gcj/bin/rmiregistry slave servertool: (null) slave tnameserv: (null) slave jre_exports: /usr/lib/jvm-exports/jre-1.4.2-gcj slave jre: /usr/lib/jvm/jre-1.4.2-gcj slave java.1.gz: (null) slave keytool.1.gz: (null) slave kinit.1.gz: (null) slave klist.1.gz: (null) slave ktab.1.gz: (null) slave orbd.1.gz: (null) slave policytool.1.gz: (null) slave rmid.1.gz: (null) slave rmiregistry.1.gz: (null) slave servertool.1.gz: (null) slave tnameserv.1.gz: (null) /usr/lib/jvm/jre-1.5.0-sun/bin/java - priority 1503 slave keytool: /usr/lib/jvm/jre-1.5.0-sun/bin/keytool slave orbd: /usr/lib/jvm/jre-1.5.0-sun/bin/orbd slave policytool: /usr/lib/jvm/jre-1.5.0-sun/bin/policytool slave rmid: /usr/lib/jvm/jre-1.5.0-sun/bin/rmid slave rmiregistry: /usr/lib/jvm/jre-1.5.0-sun/bin/rmiregistry slave servertool: /usr/lib/jvm/jre-1.5.0-sun/bin/servertool slave tnameserv: /usr/lib/jvm/jre-1.5.0-sun/bin/tnameserv slave jre_exports: /usr/lib/jvm-exports/jre-1.5.0-sun slave jre: /usr/lib/jvm/jre-1.5.0-sun slave java.1.gz: /usr/share/man/man1/java-java-1.5.0-sun.1.gz slave keytool.1.gz: /usr/share/man/man1/keytool-java-1.5.0-sun.1.gz slave kinit.1.gz: /usr/share/man/man1/kinit-java-1.5.0-sun.1.gz slave klist.1.gz: /usr/share/man/man1/klist-java-1.5.0-sun.1.gz slave ktab.1.gz: /usr/share/man/man1/ktab-java-1.5.0-sun.1.gz slave orbd.1.gz: /usr/share/man/man1/orbd-java-1.5.0-sun.1.gz slave policytool.1.gz: /usr/share/man/man1/policytool-java-1.5.0-sun.1.gz slave rmid.1.gz: /usr/share/man/man1/rmid-java-1.5.0-sun.1.gz slave rmiregistry.1.gz: /usr/share/man/man1/rmiregistry-java-1.5.0-sun.1.gz slave servertool.1.gz: /usr/share/man/man1/servertool-java-1.5.0-sun.1.gz slave tnameserv.1.gz: /usr/share/man/man1/tnameserv-java-1.5.0-sun.1.gz Current best' version is /usr/lib/jvm/jre-1.5.0-sun/bin/java.

Matt

On Sat, 2005-08-06 at 14:57 -0400, Jim Perrin wrote:

If you want to use what you already have, you will need to add an entry to your path. You can do this on a per-user basis by editing the .bashrc or .bash_profile files with an entry like

PATH=$PATH:/usr/java/jre-xxx/bin export PATH

Assuming your /usr/java contains a directory named jre-1.5.0_01

To find the Sun java executable first, you need to put the jre bin directory on the beginning of the path:

PATH=/usr/java/jre-1.5.0_01/bin:$PATH export PATH

After updating your .bashrc or .bash_profile be sure to log out and back in again to pick up the changes...

Rich