• Please review our updated Terms and Rules here

Java on the VAX

S

silcreval

Experienced Member
Joined
Mar 15, 2009
Messages
96
Location
UK
Was there ever an attempt to port Java to VAX machines? I heard there was an issue with IEEE floating point at the time, but wondered if that was ever worked around?
 
It runs on OpenVMS but it's not clear which CPU architectures; I can only find info on Itanium and Alpha CPUs.
 
silcreval said:
Was there ever an attempt to port Java to VAX machines? I heard there was an issue with IEEE floating point at the time, but wondered if that was ever worked around?
Click to expand...

IIRC, there was a version of JAVA for OpenVMS VAX, but it was like version 5 and very, very old. So old that I don't think you'll find it online anywhere. Someone might have a copy stashed away on their local system, but that's the only place it's likely to be. I don't have a copy and I have a lot of semi-old stuff.

It was the IEEE floating point that was one of the issues going to Java 8

MrImprovement said:
It runs on OpenVMS but it's not clear which CPU architectures; I can only find info on Itanium and Alpha CPUs.
Click to expand...
That's all there is online these days. Plus the beta for x86 OpenVMS Java. Even that is only Java 8. VSI is working on Java 11, but only for x86 and Itanium. Alpha is stuck at Java 8.
 
I maintain a few old Java packages and some new ones, so its always interesting to run stuff on unusual architectures.
 
pbirkel@gmail.com said:
Can you summarize why that was? What are the distinguishing characteristics of "old architectures" in this regard?
Click to expand...
raw clock speed? Lack of memory? "Just-in-time" compilation does not yield expected Benefit?

I know its also dire on my Sun Sparc box, and pretty much unusable on an Atari TT (32Mhz 68030)

... also the fact you are throwing away the possibility of compilers being tuned to the exact hardware...
 
g4ugm said:
raw clock speed? Lack of memory? "Just-in-time" compilation does not yield expected Benefit?

I know its also dire on my Sun Sparc box, and pretty much unusable on an Atari TT (32Mhz 68030)

... also the fact you are throwing away the possibility of compilers being tuned to the exact hardware...
Click to expand...
So on my SS2 Java 1.1 runs reasonably well. You can run the SwingSet demo and its not too laggy. On a SS20 with quad CPUs its really quite usable and in fact I use this machine for dev as it supports most of the early Java versions up to 1.4. Ultras seem to run it fine.

The performance on an SS2 is actually quite remarkable - as you say running Java on a 68040 (e.g a Mac Quadra) is challenging.

For your TT are you using MiNT? I wasnt aware of a Java version for the TT/Falcon ?
 
silcreval said:
I guess the later Alphas supported Java though?
Click to expand...
Define "later Alphas"... Currently an old version of Java8 is available for Alphas in the DS10/15/20/25 era. I'm not sure if there was a version for older ones such as the AlphaStation xxx series or the AlphaServers in the 2100/800/1200/4100 series. I think so but maybe the newer versions work on them too. I never tried when I had an 800 and a 1200.
 
>... also the fact you are throwing away the possibility of compilers being tuned to the exact hardware...

Right. Except as an academic exercise, why bother?
"Why run a virtual machine, when you have a REAL machine?".
 
"Why run a virtual machine, when you have a REAL machine?".

Its a good question. I guess the answer has to be portability. Although even Java struggles with that at times. I find with the modern JIT designs though its fast. The main delay is loading all the class files. Even that has been addressed though with GraalVM where you can compile to an exe for some platforms.
 
One project which always amazed me is

jainja.thenesis.org

Jainja

Jainja is a JVM (Java Virtual Machine) written in Java. Focus is set on portability, not on performance. Currently the supported platforms are Linux, Windows, DOS, xBSD, Minix, Haiku, HelenOS, RTEMS, Genode, Fuchsia OS, RISC OS, Java SE, Java ME, Android, Javascript (GWT, TeaVM or Emscripten),
jainja.thenesis.org jainja.thenesis.org

This offers some level of Java support on platforms that 'regular' Java doesnt reach - e.g. DOS and webassembly.
 
silcreval said:
"Why run a virtual machine, when you have a REAL machine?".

Its a good question. I guess the answer has to be portability. Although even Java struggles with that at times. I find with the modern JIT designs though its fast. The main delay is loading all the class files. Even that has been addressed though with GraalVM where you can compile to an exe for some platforms.
Click to expand...
Originally I believe another reason was to promote security. So it has features to prevent things like buffer over runs, but it seems in practice it has more holes than swiss cheese.

One of my issues is version sensitivity. Before I retired, which was admittedly 10 years ago, I managed an environment where we had multiple Java apps, the sensitivity of these apps to Java versions amazed me. Even worse we found old releases squirreled away bundled in apps. I also got caught in the tail of the MSJAVA debacle...

... so not my favourite tool...
 
"One of my issues is version sensitivity" - 100% on that, especially the early versions. Things settled down a bit with Java 8, and I still target that for a lot of work. As far as Java goes though things have picked up in the last 5-10 years and seeing a lot more development in the language and new front ends like Kotlin, etc. Given Java 8 was 2014, and we are now on 23 :)
 
In about 2002 at Compaq (our team had been DEC StorageWorks before the purchase) I had been the team lead for the Enterprise Volume Manager software product, and it was C++, and working fine. The package included "host agent" apps that were ported to several platforms (Windows, several Unix flavors, etc.). Then a sister site in Louisville was shut down, and their SW team was moved to CXO. They were assigned to my EVM project (I was not given a choice). Their team were Java people, and they were very experienced and competent (good people). I was effectively side-lined, and they decided that the entire product needed to be ported to Java. So I did some Java work for awhile. Not my favorite thing. The portability of Java was supposed to eliminate the multiple ports for the various 'host agents', of course. Seemed good on paper.
A few months later, I moved to the EVA Firmware Diagnostics team (whew!) - working in C, diddling HW bits, reading schematics - Yay!!
Some months later, the "Java folks" had to re-port the 'host agents' back to C++, because of various issues with the Java VM's ... I felt a little bit vindicated.

Pete
 
Last edited:
saipan59 said:
...Enterprise Volume Manager software product, and it was C++, and working fine. The package included "host agent" apps that were ported to several platforms (Windows, several Unix flavors, etc.).
...and they decided that the entire product needed to be ported to Java.... The portability of Java was supposed to eliminate the multiple ports for the various 'host agents', of course. Seemed good on paper.
Click to expand...
For something so disk and file-system related, my first instinct would be that a port to Java does not sound good, on paper or otherwise. I could be wrong, of course, but one would have to have a serious look at what Java's going to do for that, and what you're going to need to overcome. Java does not make platform differences magically go away; mainly it just lets you avoid recompiling. But you can write C++ that's just as portable, if you don't mind recompiling.

saipan59 said:
Some months later, the "Java folks" had to re-port the 'host agents' back to C++, because of various issues with the Java VM's ... I felt a little bit vindicated.
Click to expand...
Lol. "We have taken away all the old platform incompatibilities and replaced them with new and different platform incompatibilities."
 
You must log in or register to reply here.
Back
Top