Updating Java ad hoc

If one somehow depends on Java and it's not the case of a legacy dependency which will be insulated on an island system of yet very restricted subnetwork, then it will certainly need to get Java updated from time to time, because of security fixes and required new functionalities and support. But in addition, if the system isn't a more recent Solaris 11 where one can't or doesn't want IPS taking care of the update, then it will be necessary to perform an ad hoc Java update. That's probably the case with a Solaris 11 Express system or even Solaris 10, although I do highlight that in case of a Solaris 10, perhaps fortunately there's an additional option to using the old SVr4 package system to get the update in place in a presumably easier way.

The Java Archive

One may get to the official The Java Archive (as I call it) download page which link is found to the bottom of the official Java SE Downloads page. As dully warned by Oracle the legacy artifacts are unsupported and security flawed:
 

"The Java Archive offers access to some of our historical Java releases. WARNING: These older versions of the JRE and JDK are provided to help developers debug issues in older systems. They are not updated with the latest security patches and are not recommended for use in production."

Updating Java via IPS

The world knows Java, for the good, and for the bad, whatever. Bottom line is one way or the other you're gonna need to handle its existence and pervasiveness. Fortunately, Java is Oracle's as well as Solaris is and thus there's an easier way of handling it via IPS, even if one doesn't have an agreement for having access to an IPS support repository. This post is about a more streamlined way of how to do it based on the article: How to Update Only Java on Your Oracle Solaris 11 System. For this post I assume just a publicly available Solaris 11.3 GA system.

Terminator

Terminator (by Chris Jones) is a very convenient command-line GUI middleware. That's because it excels on multiplexing a single GUI window for multiple GNOME terminals. One could try to achieve similar results by simply running GNU screen with multiple (split terminal) regions within a single GNOME terminal but in the end it can't keep up with all the features of a specialized GUI software as Terminator. The main focus of GNU screen is not the GUI thing, but the underlying shell process thing.

Under Solaris 11.3, Terminator is dependent on Python 2 and GTK+ 2:

The command-line GUI

To achieve an efficient and functional UNIX command-line interface should be easy, but that's not always the case, because of the myriad of options and personal tastes, needless to say the many specific scenarios with unique requirements that may come into play.

On the seek for the "perfect terminal" I actually like to combine three things:

• GNOME terminals
  The fundamental underlying GUI terminal.
   
• Terminator
  The fundamental GUI window multiplexer.
   
• GNU screen
  The fundamental underlying shell process preserver.