Posted by ctrueden on
URL: https://forum.jogamp.org/Java-3D-Use-Maven-to-build-and-publish-Maven-artifacts-tp4035555p4035803.html

@hharrison wrote:
> poke me in a week or so

Ping.

Also, there is a new wrinkle, which I am struggling with how to solve, and I would value input from the JogAmp community.

OS X 10.11 "El Capitan" has a new feature, System Integrity Protection (SIP), a.k.a. "rootless" mode, which disallows modification to various folders, including /System, even as root.

Unfortunately, /System/Library/Java/Extensions houses the obsolete Java 3D 1.3 JARs + associated native libs, which when invoked from Oracle Java 8, crash the JVM. And even with Java 3D 1.6 libraries on the classpath, the old Java 3D 1.3 always takes precedence because /System/Library/Java/Extensions is on OS X's java.ext.path by default.

I thought of two different ways to address this new difficulty:

1. Shade the package prefix(es) of Java 3D 1.6 to avoid a clash.
2. Manually manipulate the java.ext.path.

Option 2 is a deployment-centric solution, which only solves the problem in environments where tweaking the Java runtime parameters is possible. It is also a pain because there is no way to simply blacklist the undesirable directory; instead, the java.ext.path must be built from the ground up to include all the directories which Java includes by default, except for /System/Java/Library/Extensions. Furthermore, there _are_ libraries in said directory that might continue to be useful for ImageJ users, such as the support for AppleScript. It would be a shame to lose access to _all_ Apple-specific Java extensions, just because of three bad apples (the old Java 3D 1.3 JARs).

It seems to me that choosing a new package prefix would make more sense. It would mean that legacy code needs to be refactored, but the changes would be trivial updates to import statements, easily accomplished via global search-and-replace.

Does anyone see anything I'm missing here? Any other possible ways to avoid the Java 3D OS X apocalypse?