[OmniOS-discuss] Oracle Java v7u65

[Alexander Lesle]

Hello Jim Klimov,

No, I havent.

Thank you very much for your informations and tips.

On Juli, 25 2014, 10:47 <Jim Klimov> wrote in [1]:

> Did you previously use and manage Java, on solaris, ilkumos or other oses?

> There is a JAVA_HOME environment variable (set in shell, profile,
> initscript, smf attribs, etc.) that points your Java program such as
> tomcat, or a cli tool, or some gui installer or whatever to the
> installation location of the jvm you want to use in this case. Of
> course, the "java" program for this jvm instance  should be from the
> corresponding "$JAVA_HOME/bin" path.

> So you can have multiple installations and many JVMs running with
> different versions (there are programs where backwards compatibility
> does not cut it and you do need an older version of Java for example).

> It is customary to install Solaris java's into
> /usr/jdk/instances/<versioncode>/ and symlink /usr/jdk/latest and
> /usr/java to the directory with the version you need most likely,
> and a dozen programs in the standard PATH like /usr/bin/java are in
> fact symlinks to /usr/java/bin/java and such.

> For hosts where /usr is system-managed and should not be touched by
> users according to some policy, /opt/jdk, /opt/java or plain
> /opt/<versioncode> are commonly used as containers for jre/jdk
> installations (typically as unzipped archives, unpackaged). It still
> makes sense to maintain /opt/java or even /usr/java (if changeable)
> to point to the installation this zone needs.

> Note that for some java versions the x86_64 package or archive only
> includes the 64-bit files and should overlay a 32-bit jvm of the
> same version installed/unpacked into the same location. For other
> oses or major java versions the releases are fully sufficient. An
> indicator may be the file size (i.e. 80mb 32-bit + 10mb 64-bit vs. both similarly-sized).

> As a hint, if you use many local zones to host farms of java
> appservers,etc., you'll find that updating java's consistently
> (especially un-packaged) has a large footprint in storage and
> management, more so if you customize the jdk installations (local
> CA's, most recent timezones and so on). Instead, I
> install/unpack/customize once in the GZ (one best-compressed dataset
> per jdk in a structure resembling the standard solaris jdk
> installation), and lofs-mount the whole lot into the local zones. If
> certain zones need more customization, you can clone off their copy
> of jdk dataset and delegate into the zone, but we've never needed
> that beyond some testing of the approach (cumbersome but works and
> saves space). Also, once you've completed this update on one host,
> it is easy to 'zfs-send' to your other GZ's hosting LZs with javas.

> HTH,
> //Jim

> Ps: OTN = Oracle TechNet 
> --
> Typos courtesy of K-9 Mail on my Samsung Android


-- 
Best Regards
Alexander
Juli, 25 2014
........
[1] mid:1456d13f-43ac-42f1-a21f-feec284f8b6c at email.android.com
........