The Cross-Platform Nightmare

Posted by Skrud at Monday, October 17th 2005 at 5:38pm

I can just imagine everyone seeing the title of post and shaking their heads, shriveling their brows and frowning. I bet they’re thinking “Skrud, you should be writing in Java. It’s cross platform.” Well, I haven’t even begun to tell you about my nightmare yet.

It’s a complete myth that the cross-platformability of any code is dependent upon the programming language it’s written in. It drives me crazy when people tell me that Java is wonderfully cross platform. That’s just marketing. In case you don’t believe me, take a look at the platforms that Sun releases Java for: Solaris Sparc (Sun’s own platform), Intel i586, AMD64. What about Java on Alpha? Well there are builds by HP. Java on PowerPC? Apple has its own builds. So you see, Java is as portable as the VM, and Sun only releases the VM for their own Sparcs and the popular Intel platform. All the other platform builds are released by third parties. How exactly is this different from having a C compiler on different platforms? Or even just telling gcc to cross-compile. How many platforms is GCC released for? I don’t know, why don’t you count.

But this isn’t about any language being better than any other, and this also isn’t about the JVM. Again, being cross-platform means writing portable code. You can write portable code in any language. (Java included). You can also not write portable code in any language, Java included. Portable code has no platform-dependent aspects and will run smoothly with a negligible effort of porting. Portable code has a limit, and it has to be able to adapt to different platform specific properties. This means that for each target you’ll have some source code files that need to be reimplemented, changed, etc. In the case of operating systems, this is unavoidable. By nature, an operating system needs to interface with hardware. You must have processor-dependent source code for the parts that need to be processor-dependent. Take a look at the Linux kernel. A lot of the processor dependent features are handled through macros that automatically replace certain snippets of code with the processor-dependent feature that is needed. There are also different source trees for different platforms. These separate source code files are not portable, which means that your entire product can only run on as many platforms as you’ve manually configured it for. In the case of Java, you have standard implementations of awt, swing, and swt that make your life easier. Because these are environments that exist on virtually every platform that Java does.

But I’m not talking about operating systems either. What I’m talking about is Java3D. Java3D is supposed to be a development platform for 3D graphics and “Advanced Imaging” for Java. It is not cross platform. A program is certainly not cross-platform if it can only be built on Sparc, i586 or AMD64. i586 and AMD64 are both versions of the i386 platform anyway. So they’re really the same thing. If you want them to run on a different platform, you’ll need to build the libraries yourself. If the code is written portably, you should have no problems compiling the source code, linking against your own system’s libraries, and having a nice custom version that will work on your PC. Unfortunately Java3D isn’t written like that.

You know something is wrong if the build instructions look like:

1. Add this to the j3d-core/build.xml file:

   <condition property="isMacOSXOnPPC">
   <os family="mac" arch="ppc"/>
   </condition>

2. Add a build target for Mac OS X, too:

   <target name="setupMacOSX" if="isMacOSXOnPPC">
   <property name="ostype" value="macosx"/>
   <property name="platform" value="macosx-ppc"/>
   </target>

3. Re-implement javax.media.j3d.J3DGraphicsConfig, javax.media.j3d.NativeScreenInfo, javax.media.j3d.NativeWSInfo to use MacDrawingSurface.

And to boot these aren’t official build instructions, I found them on a forum. There are no official build instructions for OS X. You know, there actually _is_ a sun.awt.MacDrawingSurface class that they could’ve used. There’s also an X11 implementation for OS X that they could’ve used, since the Linux version of Java3D uses X11 it shouldn’t be too difficult to port. But a better question would be: why are they not using portable windowing code to begin with? Probably for speed/performance reasons, but still – what’s the point of a Java API that only works on 2 different platforms? (And seriously, how many people use Sparcs?)

This comes as I’m trying to get more involved with the UGENE project, and while talking with Jon Benn this afternoon I was trying to get Java3D to build on my PowerBook. Since Mac OS X is one of our target platforms, if it really does prove to be infeasable to build on OS X we’ll have to move to a platform other than Java3D. He suggested OGRE 3D, which is a C++ API. Looks like the foray into Java has come to a grinding halt.

Tags: code, geek, linux, mac, tech 5 comments