Support for Java in OpenVMS has increased over the years, and now Java for OpenVMS on Integrity is part of the basic system, and includes Java JDK 6.0 and JRE 6.0.
Installing the Secure Web Server (SWS) – based on Apache – you also get Tomcat and Perl for free.
As long as OpenVMS remains viable, I personally expect both Perl and Java to flourish on this platform. Especially, when not using Perl for typical administration tasks, I expect that Java will be available for more powerful duties.
I would even expect to be able to put things like Stripes, Spring, or even Scala and Lift onto OpenVMS. With the portability of Java, one could potentially just copy over class files, Java archives, or even web application archives and expect things to (mostly) work.
The support for both Perl and Java on OpenVMS makes for an exciting time – and Tomcat to boot.
Share your experiences with Java on OpenVMS…
6 thoughts on “Why Java is the Future for OpenVMS”
Java has been part of the base install of OpenVMS for a long time. JDK 1.1.8 was on OpenVMS Alpha v7.2 in 1999. It’s portability certainly makes it attractive for some things, though my use tends to be almost opposite of yours. If I’m playing around with something like a remote desktop client or other GUI tool on my hobbyist system at home, I tend to use Java. If I have a serious problem to solve in a short amount of time, I use Perl.
It’s true I don’t have any heavyweight applications running in either Perl or Java on OpenVMS — those still tend to be in BASIC. In any case, I’m not trying to start a language war; I think every OpenVMS system should have both Java and Perl available.
However, has Tomcat been on that long?
I agree that Java would be for more heavyweight applications and Perl is good, quick, and right there for when you need it.
I can scarcely imagine a website running SWS (Apache) with Perl and Tomcat and Java and …? Makes OpenVMS sound modern again 🙂
I used Java on VMS in 1996 or 1997, I believe. (I also wrote a Java template for LSE.) I know I was using Perl on VMS at the time, having written a 20KLOC script that generated database access code in Pascal and SQLMOD (and, with a new code-generation subclass added, C++, and eventually some Java). At the time, I think one had to adjust the file attributes for class files after copying them to the VMS machine, or they’d cause problems.
I remember writing a small client/server applet that (I believe) used RMI to query an Rdb database, displaying the results in a scrolling field in a browser. It actually breezed very quickly through the list of, shall we say, current and former “residents” of the county facility whose Jail Management System I was working on at the time.
The portability (outside of the file- or record-attribute munging) was what caught my attention: I had a few applets that I demonstrated being served by PCs and VMS and running in a browser on the PC (I think I had a browser running the applets on VMS, too, but that’s a long time ago now). However, my suggestion that we re-tool the Jail Management software as a game-like “Age of Inmates” fell flat, and we went back to coding in Pascal.
What about: Erlang, Google Protocol Buffers, Twitter API, RabbitMQ, ZeroMQ, gSOAP, WSIT to mention just a few? Scala is already on OpenVMS, as is PHP and other LAMP products. Lots of work going on in the proting space to make things easier when porting to OpenVMS too.
Do have a quick look at http://www.johndapps.com/ No, this is not (yet) an official HP site, but, it has the support of the OpenVMS group who presents on some of the products.
Scala is on OpenVMS because Java is. Same can be said of RabbitMQ and others – possible Clojure, Groovy, JRuby, and Jython as well.
I thought when I examined PHP that the version released as part of SWS only worked in the web context, and not in the context of a command line scripting language (which the full language allows).
The thing that makes Java and Perl quite interesting is that they are HP supported – and PHP, for that matter. The others are not HP-supported as I understand it. Java JAR files should (probably) run without too much fuss; other languages require a recompile both of themselves and their released code.