If you had told me last year that I would initiate the porting of Java 3D to JOGL 2.0, I wouldn’t certainly have believed you. This is what happened February, 10th, 2012. In January 2008, Sun Microsystems focused on Prism, JavaFX scenegraph, to the detriment of Java 3D. Since, it has not changed, it has only received relatively minor corrective updates. This port (that I did for free) only took me a few hours and is now maintained by an employee of the company Ausenco Sandwell.

Harvey, the employee in question, succeeded in driving Java 3D more stable long before my intervention, he also repaired the offscreen rendering, he righted the procedure for compiling and creating JARs, it deleted a lot of dead code and removed some rarely used and potentially buggy features (including support of Nvidia Cg language for shaders). Java 3D had three rendering systems based on different APIs for graphics acceleration, two of them were based on OpenGL and the last was based on Direct3D. The rendering system used by default depended on the platform and could be selected with the property « j3d.rend ». This made the installation quite complicated (we had to plan several scenarios by setting the classpath and library path so that different systems can work) and the maintenance quite heavy for an highly questionable gain. Only the rendering system based on JOGL 2.0 has been retained. Thus, there is no risk of conflict with Direct3D (still think about disabling the Java 2D pipeline based on Direct3D if necessary), it is possible to mix OpenGL rendering code (with or without JOGL 2.0) to the Java 3D rendering code.

I advise you to get all JARs, including those that are not necessary for the execution of your program on your operating system because they will be useful to deploy it on Internet as an applet or as a Java Web Start application.

You just have to copy all JARs above into the same directory (so that JogAmp knows where to find the native libraries during the automatic extraction and loading) and put those whose name does not contain the word « natives » into the classpath. The chosen directory must be neither in the JVM (jre/lib/ext) nor in one of the directories of the extension mechanism (/Library/Java/Extensions/, /System/Library/Java/Extensions/ and /System/Library/Frameworks under Mac OS X) nor in a directory mentioned in the CLASSPATH environment variable in order to avoid any conflict between the version that you use and a version loaded in priority installed in one or several of these directories.

You can run your program as well in command line (replace « : » by « ; » under Windows, replace [1] by the relative path of your JAR or of your .class files and [2] by the full name of the main class which contains the packages and subpackages):

Setting java.ext.dirs to « » allows to stop using the obsolete versions of Java 3D installed as an extension (which can prove to be particularly useful under Mac OS X). This workaround works very well except in the applets and in Java Web Start applications as some versions of the JVM take into account this parameter only if it is set very early, if the support of java-vm-args isn’t broken and if this parameter is considered to be safe. You can package your application with OpenJDK to solve this problem once for all.

Warning: This « trick » can break some core features of Java implemented as extensions, especially the support of JAR and ZIP archives in NIO 2: java.nio.file.FileSystemNotFoundException: Provider « jar » not installed

There is a more reliable but more difficult to implement solution: modify the names of the packages in javax.media for JOGL and Java 3D and then recompile them. The problem will be resolved soon for JOGL according to this bug report but not for Java 3D.

If you get a java.lang.NoClassDefFoundError or a java.lang.NoSuchMethodError even by scrupulously following my instructions, uninstall all obsolete versions of Java 3D, JOGL or GlueGen at least the time to do your development (some applications based on these libraries may need them) either by uninstalling the corresponding packages or by removing their JARs from the directories in which it is discouraged to install Java 3D listed in the previous section.

If you get an error message of the type « Exception in thread « main » java.lang.NoClassDefFoundError: apple/awt/CGraphicsDevice » (or « Exception in thread « J3D-Renderer-1″ java.lang.NoClassDefFoundError: apple/awt/ComponentModel »), uninstall the obsolete versions of Java 3D (this is quite common on some versions of Mac OS X) at least the time to do your development (some old applications based on Java 3D may need it). This error occurs with all versions of Java 3D that rely on JOGL 1 including the old pre-versions of Java 3D 1.6. You must remove the JAR files and the .jnilib files of Java 3D, JOGL and GlueGen from all directories in which the old versions of Java 3D are installed, these are the directories in which it is discouraged to install Java 3D listed in the previous section.

If you get an error message of the type « Exception in thread « main » java.lang.NoClassDefFoundError: sun/awt/CGraphicsDevice », install OpenJDK or Oracle Java. Java 3D 1.6 isn’t compatible with Apple Java, make sure that it’s not this version that is used.

If you get a java.lang.NoClassDefFoundError or a java.lang.NoSuchMethodError even by scrupulously following my instructions, uninstall all obsolete versions of Java 3D, JOGL or GlueGen at least the time to do your development (some applications based on these libraries may need them) by removing their JARs from the directories in which it is discouraged to install Java 3D listed in the previous section.

This version 1.6.0 drives Java 3D more stable and easier to use. Java 3D gets rid of a limitation thanks to JOGL 2.0 and becomes a durable software solution as is. Nevertheless, it is still very dependent on AWT which will prevent it from running under Android, its performance problems remain and its lack of modern features puts it far behind the existing scenegraphs, including JogAmp’s Ardor3D Continuation, JMonkeyEngine and 3DzzD.

It is still interesting mainly for developers with large volumes of source code based on this API. It still has many tutorials on the Internet and as the public API hasn’t been modified, the transition from Java 3D 1.5.2 to Java 3D 1.6.0 doesn’t require any code changes, I checked that with Arabian Flights by Mike Prosser. Xith3D is the most similar scenegraph from Java 3D, but it seems at a standstill in recent years. If Java 3D is sufficient for your projects, don’t hesitate to use it knowingly. The 3D visualization in Java doesn’t come down to Java 3D.