Chris Adamson's Blog

July 2003 Archives

The End (of Java3D) and the Beginning (of JOGL)?

Anecdotal evidence has been brewing for a while that the Java 3D API has been in a state of decay. Today's events seem to resolve the situation, with a much more promising future for 3D graphics in java than when we woke up this morning, even if that future doesn't seem to include Java3D itself.

Much speculation about Java3D has come from developers on Mac OS X, which has never enjoyed a publicly-available implementation of the API, despite many heated appeals to both Sun and Apple to make it happen.

In June, a thread appeared on the Apple java-dev list entitled "Any mentions of Java3D at WWDC?". In a response, Paul FIsher summarized what he'd heard and seen at JavaOne and the Apple WWDC. He wrote:
This would jive with what seemed to come out of Java One which, to paraphrase, was basically: While Sun isn't getting rid of Java3D they aren't exactly pushing it or particularly supporting it. Since JOGL was mentioned at JavaOne and Java3D wasn't you can reach your own conclusions. As others have stated over the last week or so, Java3D is not particularly likely to show up on OS X (unless Sun all of a sudden decides to simply open-source it ... given that it seems headed for the dust-bin I would settle for a 'port' of the black-down version to OS X ... performance warts and all).

The topic came up again today in a discussion of Java API's that have native-code requirements and, per apparent Sun policy, are not ported to Mac OS X. Norris Weimer connected more of the dots in his message, in which he noted:

• that the chief architect of Java3D, Doug Twilleager, was now re-introducing himself as the chief architect of the Java Games group
• that Twilleager was pointing people to a project providing open-source Java bindings to the OpenGL graphics library
• that none of the developers previously known to be working on Java3D was now known to be working on it

For those who read the tea-leaves, the message was clear: Java3D was done for, and it appeared the preferred alternative would be to use JOGL, hosted right here on java.net. It was all over but for the press releases.

The first one appeared today.

On SGI's website, the press release announces "SGI and Sun Microsystems' Software Platforms to Work Seamlessly Together with Java Bindings to OpenGL... Joint Development Agreement Will Enable Millions of Java Users to Easily Employ OpenGL for Wide Range of Graphics Needs". An identical article appeared on Sun's site, though there has not yet been a mention of the announcement on the JOGL or Java3D page, nor here on java.net.

The reaction is sure to be controversial, especially among those who have invested in Java3D. While that API will presumably continue to work as it does today, developers generally avoid buying into a technology that with no future. On the other hand, supporters of OpenGL, and developers on Java3D-less platforms are sure to be delighted, since this will get them into the 3D-in-java game.

There's also a big picture that merits consideration. The idea of Java3D was to provide an isolation layer between java and an operating system's underlying 3D toolkit - generally meaning DirectX on Windows and OpenGL on other desktop OS's. The fact that that this strategy has been rejected, apparently in favor of getting OpenGL onto Windows machines, raises interesting questions about how practical such an isolation-layer strategy is. Is it too much work to provide the appearance of a happy and fast java 3D API, and easier to just pipe calls to a native API? On the other hand, does this approach make sense for java on hypothetical operating systems that don't use OpenGL, for example game consoles? Will java paint() itself into a three-dimensional corner?

Interesting times... in the Chinese curse sort of way.

Shoeing the Other Foot

Hey, I used to work in the wireless software industry... and of course, any sentence that begins with that phrase usually ends in "and we all got laid off". Which we did. But despite that experience, I still have a passing interest in J2ME, even though that the tools for it aren't available on Mac OS X.

Earlier today on java.net, Bill Day lamented that situation. Where Bill and I part ways, is that I don't think it's Apple's responsibility to change that.

First, consider the business case: Sun collects license fees for J2ME implementations, so encouraging development of J2ME apps helps Sun's bottom line. It also helps the device maker to have software available for its device.

Apple is neither of those parties. So really, it shouldn't be surprising that the company is not diving in to spend its own development dollars to allow developers to write apps for devices that Apple does not sell, in order to drive license dollars to Sun.

After all, you don't see Apple going out of its way to encourage development of Windows apps on Macs either.

But you want to know what really bugs me? I want to know why the J2ME WTK has any native-code requirements.

Most (all?) of the tools in the JDK - javac, rmic, javadoc, etc. - are written in Java. So are servlet engines, IDE's like NetBeans, and a handful of desktop applications. And IBM even got MPEG-4 working in Java. Does anyone honestly think that you couldn't emulate a twinkie little cell-phone KVM with J2SE? Ditto, with exclamation points, for the J2ME bytecode verifier.

There's no good reason these things couldn't have been written in Java in the first place, and if there is, then it means Java is a lot less capable than we've been led to believe.

Using native code in tools and development kits retards their distribution and acceptance, especially since Sun seems determined to write Solaris versions and yet not Mac OS X versions. (Folks, Solaris is perfectly nice as a deployment server, but outside of Sun's purple walls, you don't see that many people doing their actual development on Solaris.)

I don't see this as an Apple vs. Sun issue. I see this as a Sun vs. Java issue. And Java is losing.

This work is licensed under a Creative Commons License.