1751925 Members
5231 Online
108783 Solutions
New Discussion юеВ

Java update Hell

 
Emeric
Advisor

Java update Hell

Hello,

My workstation zx6000 is currently running hp-ux 11.23 with the September 2004 patch bundle installed. Java 1.3 (both B9788AA and B9789AA) and 1.4 (both T1456AA and T1457AA) were automatically selected during installation. By the way, I've noticed that if Java 1.3 is deselected, "war files" (don't know what are these files) cannot be expanded during the installation process. Anyway, once the system is up and running, it seems that Java 1.3 can be safely removed (however some files remain in /opt/java1.3: can they be safely removed too?). My problem is for updating Java 1.4.
I can't find T1456AA and T1457AA upgrades as implied by thread http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1128835.
All I've found is the latest Java 1.4 SDK package (including the Java 1.4 RTE and browser plug-in) in the form of the jpi14venti_14213_ia.depot file. But once installed, I'm experiencing the same problem as described in thread http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1038218 (version mismatch). In this thread, the solution was to completely remove any previously installed Java 1.4 package before installing the jpi14venti_14213_ia.depot file. Unfortunately, I can't swremove Java 1.4 RTE (T1457AA) because Partition Manager relies on it. What to do? Uninstall Partition Manager too? Will it then be possible to install it again once the new Java 1.4 package is installed?

Thank you for any input/suggestion.

Emeric
4 REPLIES 4
Sameer_Nirmal
Honored Contributor

Re: Java update Hell

While removing the Java1.3 using "swremove" which you might have tried, you should check any message for a clue on why the remaining files are not removed.

If you don't need Java 1.3, you can safely remove /opt/java1.3

You don't need to remove ParMgr. Just install the new version of Java1.4 with following options ( inside swinstall menu )

1. De-select "Mount filesystems in /etc/fstab or /etc/checklist

2. select "Allow creation of multiple versions"

2. De-select "Save file replaced by patch for later rollback"
Emeric
Advisor

Re: Java update Hell

Well,

I was probably totally asleep yesterday. The jpi14venti_14213_ia.depot file only updates the Java browser plugin. That's why I had different versions reported by SAM for the Java JRE/SDK and the plugin. The rte14_14213_ia.depot and sdk14_14213_ia.depot files were also needed to upgrade the Java JRE and SDK. As a side note, I can't still make the Java plugin working with Firefox 1.5.0.8.

Regarding the removing of Java 1.3, the remaining files in /opt/java1.3 were in fact not files, but empty directories. I imagine they can be safely removed.

Sorry for the noise!

Emeric
Emeric
Advisor

Re: Java update Hell

I've found why the java plugin didn't run. It seems that Firefox 1.5.0.8 doesn't check the /opt/mozilla/plugins directory where a link to the Java plugin is automatically created during the installation of the jpi14venti_14213_ia.depot file. Creating a link on /opt/java1.4/jre/plugin/IA64N/mozilla/libjavaplugin_oji.sl in /opt/firefox/plugins solved my problem.
Dennis Handly
Acclaimed Contributor

Re: Java update Hell

>It seems that Firefox 1.5.0.8 doesn't check the /opt/mozilla/plugins

I'm not sure if that's the way it should work. But on 11.22 I had the same problem with mozilla and reading the linux readme I found this worked:
export MOZ_PLUGIN_PATH=/opt/mozilla/plugins