1.2 Weaknesses | JAVA 3D Programming | Chapter 1

1.2 Weaknesses

          Many of the strengths can be reversed and cited as weaknesses. For some programmers coming from OpenGL, there are some OpenGL features that are hard or impossible to achieve within Java 3D. Some of this audience may miss the total control they have over the scene and the rendering process. Many others, however, will quickly learn the mapping from OpenGL functions to Java 3D objects and will appreciate the productivity gains they can achieve using Java 3D.

          Although Java 3D includes some clever optimizations, a skilled developer using OpenGL and native C code may be able to achieve higher performance than a Java programmer using Java 3D. If absolute rendering performance is the top−priority for your application then you may be better off using OpenGL or another native rendering API.

          

One particular problem, inherent in Java, which can be noticeable in performance−critical applications, is the impact of the Java garbage collector (GC). The Java runtime, the Java 3D runtime, and the application code all create objects. All these objects will eventually be garbage, and be collected by the Java Virtual Machine (JVM) GC. While the GC is running there may be an appreciable system slowdown, resulting in several rendered frames being dropped. If garbage collection occurs in the middle of a critical animation sequence, the realism of the rendered scene may be lowered for the user. However, with continued improvements in GC technology, faster hardware, and well−designed and implemented applications, such considerations are no longer prevalent.

          The Java client−side APIs, and especially Java 3D, can be difficult to distribute to end users. While the biggest pool of end users run Windows, Sun has had limited success getting Java 2 (JRE 1.2) deployed on the Windows platform. Java 2 is required for Java 3D, although Microsoft’s JVM does not support Java 2. This means that end users are required to download Sun’s Java 2 implementation, install it, and then download Java 3D and install it, all prior to running your application. If you are deploying your application as an applet, the installation process is potentially more complex as some end users will have to manually copy or edit configuration files before they can view your applet. In addition a suitable version of OpenGL or DirectX must be installed and configured for the end user’s hardware and drivers. This lengthy download and installation process can lead to frustration; I think we are some way from seeing mainstream software and games companies offering consumer−grade software products built using Java 3D, or even Java 2. Many modern end users expect the convenience of point−and−click installation and do not have the computer skills to set CLASSPATH variables or debug installation problems.

          There is light at the end of the tunnel, however, as the Java WebStart project attempts to make installing and running SDK 1.2 Java applications as easy as running native applications—which may be just as well. At present it does not appear that Microsoft will be shipping any JVM with Windows XP.

          At present, the biggest groups of Java 3D users appear to be computer scientists, businesspeople, hobbyists, game developers, and programmers. These early adopters are spearheading the deployment of Java 3D for mainstream applications.