Zones with latest Java

Java, Solaris 11 and Solaris Zones

Java is seamlessly integrated in the Solaris 11 IPS packaging system, therefore you can use the repository commands to manage the installation and configuration of Java.

Install Java 7 (JRE and JDK)

# pkg install jre-7 jdk-7

Install Java 8 (JRE and JDK)

# pkg install jre-8 jdk-8


These commands, installs the incorporation version of Java defined within the Solaris 11 base version or SRU (Support Repository Update). This version however doesn't contain all the latest update to Java; to receive the latest updates to Java, you need to specify in the packaging system that for the Java packages you don't want to be limited to the SRU versions:

# pkg change-facet version-lock.consolidation/java-8/java-8-incorporation=false
# pkg update jre-8 jdk-8
# pkg change-facet version-lock.consolidation/java-7/java-7-incorporation=false
# pkg update jre-7 jdk-7

and this will bring your system up to date, with the latest Java version.

FWIW, expanding a bit this concept, if you need to select the latest
Java IPS package from your repository when automating the
installation of multiple zones, I've found it helpful the following
template file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE auto_install SYSTEM"file:///usr/share/install/ai.dtd.1">
    <ai_instance name="zone_default">
                <zpool name="rpool">
                    <filesystem name="export"

                    <filesystem name="export/home"/>
                    <be name="solaris">
                            <option name="compression"


        <software type="IPS">
                    <!-- Specify locales to install





















                    <!-- Don't install the documentation


                    <!-- Unlock the latest Java on IPS -->


            <!-- Install required software packages: -->
            <software_data action="install">




Which allows you to unlock the facet for your Java installation, directly during the zone creation.

Join the discussion

Comments ( 2 )
  • guest Saturday, May 14, 2016

    I believe the days of installing Java system-wide are over. The world has moved on. The problem with installing system-wide is that you upgrade everything in one go. In many environments it is not possible to reason about the consequences of doing so.

    Java itself is dead-easy to install. It is basically an unpack operation. That's it!

    I like better that there's a private Java install for the application. This way upgrades are much easier. Yes, it will cost you 50-80 MB more disk space per Java install but so what ??

    Because of articles like this I've come across so many sysadmins who believe that the only way to "install" Java is through some kind of package manager. The problem is that because of the system-wide impact that sysadmins refrain from upgrading because they cannot analyze beforehand the consequences of an upgrade. This gives Java the rep that there are many dependencies, can't easily be upgraded and so on.

    Just my two cents.

    PS: If you don't like the idea of per-application Java install then go for a solution in between where you unpack various Java's into /opt/java or something and potentially use symlinks to control which one is active.

  • Marco Milo Monday, May 16, 2016


    Thanks for sharing your approach; this definitely might make sense if you have many different applications (or different versions of the same application) in a single zone (global or non-global) each relying on its own Java version.

    But my use case is slightly different and I was not trying to save a few MB of disk space. Actually I'm using more, since I did not perform any 'system-wide' installation or unlock of Java facets in the global zone: therefore the global will keep using the 'standard' JVM shipped with the version of the OS. Unlocking the facet of Java just in the zone where I needed it, means that I'll have different Java versions between the global and the zone. This is because basically I see a zone as a 'container' to isolate and automate the application deployment.

    In my most frequent use cases I need to deploy *MANY* zones on a single (or multiple) machine(s), for horizontal scalability; I control my local IPS repository with all the SW versions (including Java and my application), so that upgrading Java or the Application in all the zones, it's just matter of upgrading to the latest (locally controlled) repository image.



Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.