To blog Previous post | Next post
What does it take to support Solaris?
Java is a cross platform runtime. You write your code on a platform of your choice, test it on a different platform and then push it into production on a third platform. It just works. You do not think about the differences under the hood – JVM implementations take care of it. On worst case scenario you need to tweak some minor differences once in a blue moon. For example when building Plumbr we have only a single Ant target that takes care of producing a Plumbr executable. On any platform we supported so far.
In addition, as computer science history states, the C – language was a first truly portable language. In Plumbr we also have a bunch of native code written in C, which interoperates with JVM internals. In contrast to an Ant target we build the native part of Plumbr with a makefile. It contains several conditional branches supplying suitable flags for different compilers and linkers. We use gcc on Linux or Mac for example (with different flags, however). On Microsoft platforms we use ‘cl’ which takes 29, I kid you not, command line parameters to compile a dll. Then we have bitness issue, meaning that we have to build 32 and 64 bit versions of our native code. All this means we have a single jar file and six native libraries in total to build, test and distribute. Or we used to have before today.
We’ve been asked to support Solaris as well. In numerous cases. Well, how hard can it be to support additional platform? We live in a modern world where everything is virtualized. Even Oracle products, though Ellison seems to have his mindset for different things. You can nowadays download a VirtualBox image with a Solaris Express 11 preinstalled, so it took just one day to get Plumbr working on a Solaris. Even Amazon seems to offer pre-built Solaris AMIs. I was really happy with the result, praising portability of C language, which allowed me to support new platform by creating get two additional libraries in almost no time. Now we had eight of them.
All this nirvana ended on a lunch we took with a team one day. From a few questions thrown into the air this day I started to understand that there’s more to Solaris than this simple VirtualBox image. I suddenly remembered large server racks from my IT consulting history. They were no ordinary X86 boxes. They had completely another architecture – SPARC.
I rushed to google just to discover that you can’t get a Solaris on SPARC running in any cloud (at least for a reasonable amount of money), nor you can get a SPARC Solaris as a VirtualBox image from Oracle. Well, it’s hard to virtualize completely different architecture I guess.
Fortunately, we have enough geeks among our friends. One of them is running a IT museum on his free time. And happened to have a Sun Blade 100 workstation collecting dust. Along with huge 8U boxes, he also gladly offered to us. Luckily I do not possess superpowers and was physically unable to lift those bastards. Anyhow, this Sun Blade 100 was bought in year 2002. Its ten years for those who are not good with hardcore math. And still worked. Besides the fact that the machine had it’s hard disk wiped out of anything resembling an OS.
However it had also a floppy and a smart-card reader. What a relief. It took two days just to get a Solaris installer images on CD-s, as all you can get today is a DVD image. All that just to discover that a CD-ROM drive in the Blade was unable to read those CDs. Then another day to find a CD-ROM drive with IDE interface. Do you even remember what that is? Suddenly I realized, I’ve not used desktop computers for over 5 years. Apparently one just cannot go and buy an IDE optical drive nowadays. Back to museum again. But finally Sparc Solaris 10 u7 was installed.
I won’t go into much details about the challenges faced when installing software on this box. I can just say that apt-get and rpm are really nice tools. As opposed to curl-ing through the dependency hell. You have no ideas what less for example depends upon.
But gosh, this machine is slooooooooooooow. The test suite we have needs less than ten minutes on our dev machines. In takes 3 hours to complete on that pile of history. As you can imagine, waiting for hours to discover that the tests failed is not fun. Fortunately the only problem with SPARC was driven by the fact that it is little endian, as opposed to big endian x86. So that was an easy fix.
And we also seem to have solved the heating issue as the SPARC produces so much heat we can most likely switch off the heat during this winter. I even won’t start with the noise factor. If it’s compiling a binary you feel like standing next to a jet fighter taking off.
Anyhow, a week later we can announce that the Solaris support is now available in our nightly builds. Go ahead and try it out while its still fresh!
All I can say as a summary – you’ll start appreciating Java portability when you’ll have to support one single native library on all platforms. And also I now understand all the fuss about JVM ecosystem and new languages evolving on the JVM – go try to get working your native app on all the platforms where JVMs just work. It’s darn hard without it.
Comments
SPARC of that era is big endian, and now is bi-. Opposedly, x86 is little endian, always was.