The Forgotten Workstation: Sun JavaStation

These days, conversations about Java tend to center around Oracle and Google fighting it out in court. But back in 1996, Sun was the keeper of Java and promoted it heavily. They even released a diskless workstation that only runs Java applets. The Sun JavaStation was affectionately called the “Mr. Coffee” and [Cameron Gray] wants to show you how it worked and what’s inside of it.

A single screw frees the innards from the small case. Inside looks like a dense PC from the era, although the parts inside are a far cry from a typical PC. The CPU was a 110 MHz microSPARC II soldered directly to the motherboard. The four RAM slots could take up to 64 megabytes of PC RAM.

Unlike Sun’s full-blown workstations, the JavaStation took standard PC peripherals. For example, the monitor connection is a standard VGA and there are normal PS/2 keyboard and mouse ports. The driver for this box was price, so having cheap commodity I/O was a selling point.

[Cameron’s] JavaStation had lost its configuration, so he had to use a serial terminal to reset some key parameters. After that, the machine was able to boot itself over its network connection. The operating system is — no surprise — JavaOS.

By the way, if you happen to have one of these boxes, they can run Linux. Turns out running Linux makes the box faster than the original JavaOS and offers better software choices, too. You can see Corel Office, for example, running on the box and [Cameron] says the slow loading of applications and performance was the chief complaint among users.

These were supplanted by the Sun Ray thin client, which we’ve seen converted into a Raspberry Pi computer. Of course, if you just want a thin client, you don’t need to go retro to do that.


55 thoughts on “The Forgotten Workstation: Sun JavaStation

  1. A bit of a detail but important one – these machines were designed to run *Java applications* and *not applets*! That’s not the same thing.

    Applets are very restricted in what they can do compared to applications because they were meant to run in a sandbox (typically in a web browser).

    1. It actually does run Java applets via a web browser. The stuff Cameron shows is Java applets streaming over the network and is loaded through a web browser UI. I think they had some capacity to also run standalone applications, but all the stuff in the video is applets.

      1. Just-in-time compilation appeared about a year before the JavaStation was discontinued. It survived for 3+ years with interpreted Java and the processor was a bit under-powered for the job.
        If one were to build something like the JavaStation but with a modern JVM, it would perform excellent. You kind of have seen it in action already in the form of Android.

        1. “You kind of have seen it in action already in the form of Android.”

          Huh?!? Android sucks badly performance-wise compared to every other native OS in circulation. They even had to give up making professional audio applications leaving Apple alone in the field because the Java subsystem imposes higher latency even compared to a 15 year old PC.

    1. Sadly it lives with Android OS and some bank stuff. You have to hire 2x more people to do the same stuff as in C++ or 10x more than in Python but you have all these corporate babble behind you so you can sleep calm.

      1. Emulating unsigned arithmetic isn’t exactly rocket surgery. Few things actually need it at all, in fact fewer things need it in Java than in e.g. C as the language and VM removes most portability problems.

        Java isn’t my favorite language or (virtual) machine design but it isn’t a total and obvious failure as the OP apparently think.

    1. If it’s a W2100z then it’s not a Javastation, but a machine Sun marketed specifically for Java development under Solaris x86. It’s nothing special, just a Sun-badged PC.

  2. Java is great. It’s sooo much faster than C/C++. Once the profiler runs, in a few days, the application will almost never drop user input. It just takes a little while for the profiler to run through all the code paths. Dropping user input is normal.

    1. Most software is not held back for performance reasons. It’s software development schedules that kill good software. Java tried to alleviate that in several ways, but it was not wholly successful. Architecturally you can get a lot of throughput out of a Java application, but the latency is terrible for UI work. Now that most of the sane world has moved to doing UI as web-based we can focus on back-end instead of constantly rehashing old ideas for GUIs that never seem to pan out.

  3. While working in the industry I was able to score many servers / work stations such as Sun Enterprise 450, Sun Ultra 1, 5, 60 and my favorite Sparcstation 1. ah memories,,,,,,,,,,,,,

        1. That system has 20 MHz clock, and the ancient DRAM requires about 15 wait cycles. With 10 Mbit ethernet and a truly pathetic SCSI adapter, there is no way to escape truly dismal disk performance. Compiling or running or debugging anything more complex than “hello world” is my idea of a nightmare. There is a good reason why they only made about 100 of these systems, they suck massively. Why not go down to Micro Center and spring $5 for a raspberry pi zero, you’ll get much more actual development done.

          1. Come on, until you’ve compiled on a sort of 8bit CPU running at 2MHz maximum, with two floppy drives, you don’t know “slow”. That Radio Shack Color Computer III did have 512K of RAM, but I can’t remember if the compiler really took advantage of it. All I remember is that after spending a hundred dollars for the C compiler, I soon gave up. It churned too much with just simple programs.

            I do have a Sun 3/50 in the basement, plus just a board. I got them about 1998, someone clearing a closet, and they were better than what I was using at the time, but the missing pieces were too expensive for me. My quad core 3.4GHz desktop dwarfs it by so much now.


        2. I sometimes miss my 3/50 with integrated-ish monitor. It could netboot NetBSD and, in the days when XDMCP and telnet ruled the earth, was powerful enough act as a proper graphical terminal.

    1. I’ve still got a Sun 3/260 200lb bar fridge. Something like a 100W for the cpu board (w/ b/w graphics & ethernet). I even had a couple of the early Sparc boards in the same form factor (long gone). Interestingly enough, the printer I/O board has a full i286 & i287 on board. NetBSD is quite happy on the beast. I even managed to boot two cpu boards in the chassis either due to how the vme bus is split up or I was lucky.

  4. Never saw one of those before, but I really wouldn’t have expected that case. It’s just a slightly modified SUN Unipack, the case SUN used for single external SCSI-HDs.

  5. I was a technical manager at Sun, the person whose team of System Administrators helped IT roll out 3000 of the original Sun Javastations throughout Sun (we ate our own dogfood, as Scott used to say). As this article points out, Sun’s Javastation was a microSparc and essentially PXE booted the JavaOS. One company we worked with had it to PXE boot Solaris, but even though it ran faster, that was not politically correct at a time Java was set to take over the world, and the idea was canned. Because this was before JIT, it was a dog slow machine and didn’t gain a lot of traction with our employees. It also didn’t help that our internal application development teams were reluctant to port their apps to Java. So, slow machine with no apps…most people wound up using it to hang Post-it notes…no joke. It wasn’t a bad idea, but in the beginning days of Java, it was a risky thing to do. Someone at Sun developed a true Java hardware machine. I thought that would have been a better choice than a JVM without JIT, but it never got the backing to take off.

    The second generation networked computer was a graphics card with edge electronics to handle a mouse, keyboard and a card reader. It was faster, since all processing was done in the building’s servers. Think of it as an X-windows server. You would plug in your access card, log in, and run whatever application’s you wanted. You could pull your card out, go to another networked computer, plug the card in, and voila, your session was moved there, just as you’d left it. That was pretty slick.

  6. I worked for Sun.

    They were useful boxes if you had something you didn’t want sitting on the floor. A couple of them would prop that item up quite well, and that’s what most of the ones I saw were deployed for.

    Other than that, they – and most of Sun kit in that era – are well forgotten.

    I left SGI in 1999 and joined Sun, thinking “the hardware couldn’t be that bad”. I was right: it was actually far worse than I expected. E10K’s with non-ECC caches, workstations with PATA IDE disks which took 20 mins to boot, taking a perfectly good SunOS 4.x and turning it into the mess which was Solaris (folks remember Solaris in it’s end years, when we it was a decent OS. But there was a lot of unnecessary blood, sweat and tears to get it there.)

    And don’t even get me started on Java. What a pile.

  7. > By the way, if you happen to have one of these boxes, they can run Linux.

    Shouldn’t it say “they _could_ run Linux”? Does any modern distribution still support 32-bit SPARC?

    1. As someone who has actually run sparc32 this decade:
      No, there isn’t. If you can bootstrap with debian linux kernel 2.2.19 (No idea what the actual debian release is called, and AFAIK they don’t even keep archives of it anymore!) then the gentoo sparc64 overlay can be used to build a system on them (VERY SLOWLY! Needs at least 256 megs of ram, ruling out the IPX and earlier and probably SS4/5.) As an additional problem, you can’t actually fit a modern linux kernel, even with everything disabled into the 1 megabyte address space needed by the IPX’s Openfirmware, meaning those devices are out as well (2.4 and most 2.6 kernels were furthermore broken on sun4m boxes, supposedly only getting fixed in the late 2.6 era after somebody was found who either was educated in or had documentation of what broke the sun4m support in 2.2.20 and above.)
      Additionally, most of the old sparc linux resources are long since dead. Even given some of the shortcomings of SPARC, it would be nice to see FPGA based board reimplementations with the long term goal of building openfirmware motherboard chipsets that could be shared between SPARC/RISC-V/J-Core cpu architectures with the long term goal of providing us nerds secure and open hardware, even if the rest of the world chooses to enslave itself to insecure systems with Intel ME, Arm Trustzone, or AMD Secure Processor behind the scenes, where they cannot be sure who might be peering at what on their systems. The more architectures and the more open the designs we have available, the better the odds that when true tyranny strikes, we will still have some hardware available, even if only for a generation or two, that can allow us to communicate securely around the dangers that will have unfolded.
      P.S. SDRAM, ISA, PCI, AGTL and a few other technologies should all be out of Patent. If 64 bit BAR support could be added to PCI, then PCI to PCIe Adapters could in theory allow us access to modern GPUs and other hardware up to whatever PCI bus speed was allowed. Have each PCI slot on its own bus and you have a workaround to using patented tech on the motherboards, and with GPU mining port multipliers one PCI slot+PCI to PCIe adapter can get you as many ports for peripherals as you need up to whatever bandwidth the bridging chips support (only x1 right now, but with demand comes a reduction in price…)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.