On Thu, Apr 16, 2009 at 6:22 AM, <fernando@xxxxxxxxxxxxx> wrote: > Hi, > > > Insted of doing all this, configure the EPEL repository so you can use yum to install openjdk (which > is Sun JDK 1.6.0 open sourced -- and the current EPEL rpms were certified by the JCP). Then you can > use yum o install tomcat from RHEL repositories. > > Easier than dealing with environment variables, [...] >> export JAVA_HOME=/opt/jdk1.6.0_07 >> export PATH=/opt/jdk1.6.0_07/bin:$PATH >> [...] Initially Java did not belong into the open source camp. Accordingly, those of us who are engaged with Java applications on an regular basis know that minor implementation differences by the commercial, free and open source vendors will have an effect on any (some or all) Java applications. We also know that certain Java applications will require an certain version of Java to operate as that (Java) application was designed to do. Needless to say, it is not unusual for developers, administrators, and system integrators like us --and others, to have multiple implementations and/or versions of Java in our machines. For an given session, setting first the JAVA_HOME environment variable will let the Java application under consideration "know" where to obtain its resources; further, prefixing the relevant executable directory to the PATH environment variable prevents other existing Java executable implementations and/or versions from "tainting" the integrity of the application under consideration. Of course, once the Java application is ascertained to function well with an implementation/version of Java, an relevant script and/or modification to GNU/Linux existing settings should follow. > already integrated to Linux boot and shutdown, and > getting updates the regular RHEL way (no wories about security bugs) > > > []s, Fernando Lozano > Indeed, I also subscribe to that higher Java Platonic notion represented by OpenJdk. however, in the current mundane world of Sun's legacy, an given application designed for JDK 1.4, for instance AppGate's Mindterm (< http://www.appgate.com/index/products/mindterm/ >), will yield unexpected results when run with OpenJdk. These latter sort of circumstances can be solved by exporting a couple of variables --as elaborated-- for an given session. Yes, and Java application vendors bundle the JRE and runtime environment variable modification scripts that function best with their application; relying on the end users' existing Java implementation(s) that may introduce incompatibilities and spit out errors. The no-cost, free as in beer, IBM Lotus Symphony is an example of those. -- Jose R R http://www.metztli-it.com --------------------------------------------------------------------------------------------- IBM Lotus Symphony supported on GNU/Linux, Mac OS, and Windows. --------------------------------------------------------------------------------------------- Daylight Saving Time in USA & Canada starts: Sunday 08 March 2009 --------------------------------------------------------------------------------------------- -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
