Many thanks for the history lesson, Otto. I did download what I thought was java 1.6 from
http://java.com/en/download/manual.jsp#sol It was a shell script and when I ran it, it looked like it just unzipped jre1.6.0_22 which contained a bin and a lib subdirectory. I relinked /usr/java to this directory but then the SRSS 4.2 installed failed because it couldn't find a JRE. I noticed that the java 1.5 directory had a jre subdirectory but 1.6 did not. I guess my error was that I downloaded the 64-bit version instead of the 32-bit. I had just assumed that my OS was 64-bit so that's the version I chose. Thanks again. Scott -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ottomeister Sent: Saturday, November 20, 2010 12:00 PM To: SunRay-Users mailing list Subject: EXTERNAL:Re: [SunRay-Users] SRSS 4.2 + java 1.6 On Fri, Nov 19, 2010 at 4:39 PM, Nishimura, Scott L (IT Solutions) <[email protected]> wrote: > I tried to install SRSS 4.2 [which came from a SRS 5.1 download] on a > newly-built SPARC Sol10/u9 machine and it failed because the java > installed was 1.5 and the installer wanted >= 1.6. > > [I don't know java and am assuming that 1.5=5.0 and 1.6=6.0] That's correct. For the release after Java 1.4 the Java marketing people decided that "Java 5" sounded sexier than "Java 1.5", so they made the leading "1." disappear from the product name. (This parallels Solaris release naming which dropped its leading "2." after Solaris 2.7 and became Solaris 8.) Under the hood the Java engine still identifies itself with the leading "1.", which is why the error report calls for a "1.6" engine. > This is odd because I've successfully installed SRSS 4.2 on a Sol10/u8 > machine which had java v1.5 so even though the label "SRSS 4.2" didn't > change, something internal did. The Java 6 requirement is not new . Also, except for the installer, the base "SRSS 4.2" bits in SRS 5.1 are exactly the same bits that were in the 4.2 release. If you look very closely you'll see that the installer package has a new version number. The other SRSS packages retain their original version numbers because they *are* the original 4.2 packages. However, after laying down the 4.2 base packages the new installer goes on to apply patches to that base, so what you end up with in SRS 5.1 is SRSS 4.2 plus the latest patch fixes. On the other hand, the SRWC in SRS 5.1 is a completely new release, 2.3 versus the previous 2.2. That new SRWC is the main reason for SRS 5.1. We wanted to get that new SRWC out and decided to not hold it back waiting on the next complete new SRSS release. But I digress. Getting back to your issue ... The older machine must have Java 6 installed someplace. You can install as many Java versions as you like, as long as you put them into locations that don't collide. /usr/bin/java is just a symlink to the version that you consider to be the default version. (In fact it's a usually a symlink to a symlink. You can follow that chain to see what's really going on.) The solution for this new machine is to install Java 6. Then when you install SRS 5.1 you can tell it where to find that Java 6, and it'll be happy. There is a Java 6 snapshot in the SRS image, but you should ignore that one and get an up-to-date Java 6 by downloading and installing the latest one (currently Java 6 update 22) from <http://www.oracle.com/technetwork/java/javase/system-configurations-135 212.html>. Make sure that you get the 32-bit version of Java for your platform. SRSS augments Java with some native-code libraries and those libraries are 32-bit, so the Java executed by SRSS must be 32-bit too. > Maybe if I used the SRSS 4.2 installer > that comes out of an SRS 5.0 download instead it would work. No, that would be a disaster. Not only would it fail for the same reason on the Java version requirement, but once you got past that by installing Java 6 the old installer would have no clue how to handle the SRS 5.1 installation. The installer is intimately coupled to its release. You *must* use the 5.1 installer to install 5.1. OttoM. __ Disclaimer: I am employed by Oracle. The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation. _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
