Historically, Java 3D was installed as an extension to the Java Runtime Environment, meaning that JAR files and native libraries were placed in the lib/ext directory of the JRE installation, or manually appended to the Java extensions via the java.ext.dirs system property.

However, that approach has many downsides:

• Users must install Java 3D manually, independent of the application.
• Thus, at runtime, the application cannot manage the version of Java 3D in the same was that it manages versions of its regular dependencies.
• Similarly, at build time, the Java 3D dependency must be treated specially (e.g., with Maven, using provided scope in the POM).

Failure to manage Java 3D installations as needed can result in cryptic version-skew-related error messages, such as NoSuchMethodError or even native-library-related errors. This situation is especially prevalent on OS X, where Java 3D 1.3 was pre-installed in /System/Library/Java/Extensions on older versions of the OS, and left in place after OS upgrades (despite Java itself being uninstalled).

These days, Java 3D is built on top of JOGL, and available on GitHub. But old installations of Java 3D still lurk, waiting to disrupt applications at runtime: libraries present on the Java extensions path take precedence over those on the regular class path.

This service mitigates the issue by warning users (via UIService.showDialog(java.lang.String)) if any Java 3D installations are detected as Java extensions, and asking the user to clean them up before proceeding. Consequently, applications can now use the modern JOGL version of Java 3D, without worrying about obsolete versions of Java 3D interfering at runtime.