3D graphics programming in Java, Part 1: Java 3D
Get a head start with this introduction to the Java 3D API
By Bill Day, JavaWorld.com, 12/01/98
Page 2 of 5
- Java 3D is a standard extension API. Java platform licensees are given the option to implement the API if they like, but they're not required to implement it.
Java 3D's positioning as a standard extension runs the risk of reducing the portability of Java 3D code across platforms --
most vendors have to struggle to keep up with changes and additions to the core platform alone.
- Java 3D has severe availability constraints. These are the result of Java 3D's status as an extension API. The only major vendor currently providing a Java 3D implementation
is Sun, with its implementations for Solaris and Win32. Compared to OpenGL, which is available for every flavor of Unix, Windows,
and many other operating systems, the cross-platform portability of Java 3D code looks questionable.
- Along with software availability problems come documentation deficits. Sun is making a valiant effort to provide developer training and support for Java 3D, but it is still falling short compared
to the rest of the industry's efforts in documenting OpenGL and its use. The OpenGL Consortium's Web site is far deeper and broader than anything Sun has managed to put together for Java 3D so far. This is not a minor point: the
relative complexity of 3D graphics APIs make good documentation a necessity.
- Java 3D hides rendering-pipeline details from the developer. Because Java 3D is a high-level API, it intentionally hides details of the rendering pipeline from the developer, which makes
it unsuitable for a significant number of problems where such details are important. (We'll discuss OpenGL's lower-level model
and access to the rendering pipeline later in this 3D series.)
- Java 3D components are heavyweight. That is, they have a native (non-Java) peer that actually does the rendering. This can complicate your GUI development if
you use Java Swing and its all-Java, or lightweight, components. There are some special workarounds, but in general, lightweight
and heavyweight components don't mix well in the same container objects and windows. More information on lightweight-heavyweight
component problems is available from the Resources at the end of this article.
Installing Java 3D
Now that we understand the major features and constraints of Java 3D, let's get ready to try out some example code.
Java 3D is available in beta for Win32 and Solaris. The more mature of Sun's implementations of Java 3D is built on top of
OpenGL. An alpha-quality Direct3D implementation is also available for Win32. All require Java 1.2, with the latest Java 3D
beta corresponding to Java 1.2 Beta 4. Sun has promised to release the final Java 3D implementation shortly after it releases
Java 1.2, which is currently scheduled for December 1998.
A slightly confusing aside: Sun released Java 3D 1.0 alpha implementations, which corresponded to the Java 3D 1.0 API, but
it never released anything beyond alpha for the 1.0 API. Sun then modified the API, releasing the modified version as the
Java 3D 1.1 API. This version was followed with releases of what it called 1.1 beta implementations, two so far. Sun has promised
to release a final API and implementation shortly after the final release of the Java 1.2 platform. Hopefully, the API has
stabilized and won't be revved, yet again, with the world still waiting on a bonafide final release of an implementation.