New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bundle JOGL-based Java 3D 1.6 with ImageJ #120

Closed
ctrueden opened this Issue Apr 6, 2015 · 27 comments

Comments

Projects
None yet
6 participants
@ctrueden
Member

ctrueden commented Apr 6, 2015

We want to bundle Java 3D with ImageJ, so users do not need to install anything into the lib/ext like you used to. In particular, this will make the 3D Viewer more platform independent, and help bring the 3D rendering framework of ImageJ into the 21st century.

It will also hopefully allow Java 3D to work more reliably with Java 1.8 on modern operating system versions.

As a first step, I Mavenized the JOGL-based Java 3D codebase; see:

See also these discussions:

And lastly, see the jogl-java3d branch of the 3D Viewer.

@ctrueden ctrueden added this to the 2.0.0 milestone Apr 15, 2015

ctrueden referenced this issue in imagej/imagej-launcher Apr 22, 2015

MacOSX: add missing path separator
This fixes #21 (i.e.
java.ext.dirs being set erroneously), reported by Kota Miura.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden May 13, 2015

Member

An experimental Windows 64-bit bundle of Fiji including the JOGL-based Java 3D 1.6 is available here:

Member

ctrueden commented May 13, 2015

An experimental Windows 64-bit bundle of Fiji including the JOGL-based Java 3D 1.6 is available here:

@ctrueden ctrueden added the deployment label Jun 8, 2015

@imagejan

This comment has been minimized.

Show comment
Hide comment
@imagejan

imagejan Jun 15, 2015

Member

@ctrueden The Windows 64-bit bundle worked well for me with a Java 1.8 installation after removing a previously installed Java3D (i.e. deleting the C:\Program Files\Java\Java3D folder and the j3dcore.jar and j3dutils.jar from that installtion).

Otherwise the ./jars/j3d-core-1.6.0-SNAPSHOT.jar and ./jars/j3d-core-utils-1.6.0-SNAPSHOT.jar are shaded by the existing installation.

Member

imagejan commented Jun 15, 2015

@ctrueden The Windows 64-bit bundle worked well for me with a Java 1.8 installation after removing a previously installed Java3D (i.e. deleting the C:\Program Files\Java\Java3D folder and the j3dcore.jar and j3dutils.jar from that installtion).

Otherwise the ./jars/j3d-core-1.6.0-SNAPSHOT.jar and ./jars/j3d-core-utils-1.6.0-SNAPSHOT.jar are shaded by the existing installation.

@hinerm

This comment has been minimized.

Show comment
Hide comment
@hinerm

hinerm Jun 18, 2015

Member

@imagejan Thanks for testing! Did Java 3D still work with the shaded jars, or were there exceptions?

Member

hinerm commented Jun 18, 2015

@imagejan Thanks for testing! Did Java 3D still work with the shaded jars, or were there exceptions?

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Jun 18, 2015

Member

shaded jars

Because I am a pedant, I want to point out that shading means to rename the packages to avoid name clashes. A better word here might be "shadow."

But anyway I think the situation here is clear: the Java 3D installed into your JRE's lib/ext took priority over the JOGL-based one shipped by the Fiji bundle, right? But an important question as @hinerm asked is: Did the installed Java 3D work? If not, we will probably need to add a "doctor" check to ImageJ that warns if the JRE currently in use includes Java 3D...

Member

ctrueden commented Jun 18, 2015

shaded jars

Because I am a pedant, I want to point out that shading means to rename the packages to avoid name clashes. A better word here might be "shadow."

But anyway I think the situation here is clear: the Java 3D installed into your JRE's lib/ext took priority over the JOGL-based one shipped by the Fiji bundle, right? But an important question as @hinerm asked is: Did the installed Java 3D work? If not, we will probably need to add a "doctor" check to ImageJ that warns if the JRE currently in use includes Java 3D...

@hinerm

This comment has been minimized.

Show comment
Hide comment
@hinerm

hinerm Jun 18, 2015

Member

More thoughts: currently the launcher sets the Java3D installed by the 3D viewer first on the ext.dir - causing it to take precedence even if a local Java installation has a Java3D extension. This goes against our current push to "just let stuff happen naturally", and not rely on potentially obscure low-level workarounds.

A step in the right direction would be modifying the java-info script to discover installed extensions.. and also making that logic available in Java-land. This info could then be used in a Java-selection dialog.

Member

hinerm commented Jun 18, 2015

More thoughts: currently the launcher sets the Java3D installed by the 3D viewer first on the ext.dir - causing it to take precedence even if a local Java installation has a Java3D extension. This goes against our current push to "just let stuff happen naturally", and not rely on potentially obscure low-level workarounds.

A step in the right direction would be modifying the java-info script to discover installed extensions.. and also making that logic available in Java-land. This info could then be used in a Java-selection dialog.

@rejsmont

This comment has been minimized.

Show comment
Hide comment
@rejsmont

rejsmont Jun 19, 2015

If I may comment, ImageJ 3D viewer seems to be completely happy with 1.6.0-pre12-daily-experimental I have grabbed from:

https://jogamp.org/deployment/java3d/1.6.0-pre12/

of course you also need jogl:

https://jogamp.org/deployment/jogamp-current/archive/

and need to ditch the now-supplied 1.5

rejsmont commented Jun 19, 2015

If I may comment, ImageJ 3D viewer seems to be completely happy with 1.6.0-pre12-daily-experimental I have grabbed from:

https://jogamp.org/deployment/java3d/1.6.0-pre12/

of course you also need jogl:

https://jogamp.org/deployment/jogamp-current/archive/

and need to ditch the now-supplied 1.5

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Jun 19, 2015

Member

@rejsmont Indeed, we have found that the JOGL-based Java 3D 1.6 works great. At this point, it is not the software that is the problem, but the deployment.

Java 3D 1.6 + JOGL are deployed like any other library: using JAR files on the classpath. The JOGL libraries do ship native libs internally, but all works seamlessly thanks to the talented JogAmp team (thank you @io7m, @gouessej and @hharrison!).

In contrast, Java 3D 1.5 and earlier are installed as Java platform extensions, which take precedence over everything on the classpath, As you say, you need to "ditch the now-supplied 1.5"—and furthermore you must uninstall Java 3D from whatever JRE is selected by the launcher. Otherwise, these versions of Java 3D will take precedence over the JOGL one.

To fully address this and close out this issue, we must:

  • Upload the JOGL fork of Java 3D to a Maven repository. In the short term we will likely use my Mavenized fork [1, 2, 3] but of course it would be good to consume official JogAmp Java 3D artifacts from Maven Central once they exist; see hharrison/java3d-core#14.
  • Update 3D_Viewer to use the JOGL fork of Java 3D (done on a branch).
  • Improve 3D_Viewer to check for Java platform extension versions of Java 3D and warn the user about them (how loudly to warn will depend on whether Java 3D 1.5 even works with the 3D Viewer on OS X these days—would like to hear back from @imagejan about that!). Note that when we switch away from the ImageJ Launcher in favor of JavaFX self-contained application bundles, the java/macosx-java3d folder will no longer be destructively added to the java.ext.dirs (in fact we will steadfastly avoid touching java.ext.dirs at all), which should help simplify matters a bit.
  • Upload these updated components to the ImageJ update site. This entails migration of the 3D Viewer into ImageJ2 core. (Right now it is part of Fiji, and also included with vanilla ImageJ 1.x, but not bundled with plain ImageJ2, which is pretty confusing.)
Member

ctrueden commented Jun 19, 2015

@rejsmont Indeed, we have found that the JOGL-based Java 3D 1.6 works great. At this point, it is not the software that is the problem, but the deployment.

Java 3D 1.6 + JOGL are deployed like any other library: using JAR files on the classpath. The JOGL libraries do ship native libs internally, but all works seamlessly thanks to the talented JogAmp team (thank you @io7m, @gouessej and @hharrison!).

In contrast, Java 3D 1.5 and earlier are installed as Java platform extensions, which take precedence over everything on the classpath, As you say, you need to "ditch the now-supplied 1.5"—and furthermore you must uninstall Java 3D from whatever JRE is selected by the launcher. Otherwise, these versions of Java 3D will take precedence over the JOGL one.

To fully address this and close out this issue, we must:

  • Upload the JOGL fork of Java 3D to a Maven repository. In the short term we will likely use my Mavenized fork [1, 2, 3] but of course it would be good to consume official JogAmp Java 3D artifacts from Maven Central once they exist; see hharrison/java3d-core#14.
  • Update 3D_Viewer to use the JOGL fork of Java 3D (done on a branch).
  • Improve 3D_Viewer to check for Java platform extension versions of Java 3D and warn the user about them (how loudly to warn will depend on whether Java 3D 1.5 even works with the 3D Viewer on OS X these days—would like to hear back from @imagejan about that!). Note that when we switch away from the ImageJ Launcher in favor of JavaFX self-contained application bundles, the java/macosx-java3d folder will no longer be destructively added to the java.ext.dirs (in fact we will steadfastly avoid touching java.ext.dirs at all), which should help simplify matters a bit.
  • Upload these updated components to the ImageJ update site. This entails migration of the 3D Viewer into ImageJ2 core. (Right now it is part of Fiji, and also included with vanilla ImageJ 1.x, but not bundled with plain ImageJ2, which is pretty confusing.)
@imagejan

This comment has been minimized.

Show comment
Hide comment
@imagejan

imagejan Jun 23, 2015

Member

@ctrueden I tested the 3D viewer on OS X in various configurations:

  • Java 1.6 and Java3D 1.5 (standard Fiji installation) works fine
  • running with the default JRE installation using
    --java-home='/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Home' finishes immediately without output
  • after installing JDK 1.8, running with --java-home=/Library/Java/JavaVirtualMachines/jdk1.8.0_45/Contents/Home produces the following error:
version = 1.5
/Users/faim/.ImageJ_3D_Viewer.props (No such file or directory)
Exception in thread "J3D-Renderer-1" java.lang.UnsatisfiedLinkError: no jogl in java.library.path
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1865)
    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
    at java.lang.System.loadLibrary(System.java:1122)
    at com.sun.opengl.impl.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:189)
    at com.sun.opengl.impl.NativeLibLoader.access$000(NativeLibLoader.java:49)
    at com.sun.opengl.impl.NativeLibLoader$DefaultAction.loadLibrary(NativeLibLoader.java:80)
    at com.sun.opengl.impl.NativeLibLoader.loadLibrary(NativeLibLoader.java:103)
    at com.sun.opengl.impl.NativeLibLoader.access$200(NativeLibLoader.java:49)
    at com.sun.opengl.impl.NativeLibLoader$1.run(NativeLibLoader.java:111)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sun.opengl.impl.NativeLibLoader.loadCore(NativeLibLoader.java:109)
    at com.sun.opengl.impl.macosx.MacOSXGLDrawableFactory.<clinit>(MacOSXGLDrawableFactory.java:53)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:108)
    at javax.media.j3d.JoglPipeline$QueryCanvas.<init>(JoglPipeline.java:9010)
    at javax.media.j3d.JoglPipeline.getBestConfiguration(JoglPipeline.java:8774)
    at javax.media.j3d.Renderer.doWork(Renderer.java:495)
    at javax.media.j3d.J3dThread.run(J3dThread.java:256)
Member

imagejan commented Jun 23, 2015

@ctrueden I tested the 3D viewer on OS X in various configurations:

  • Java 1.6 and Java3D 1.5 (standard Fiji installation) works fine
  • running with the default JRE installation using
    --java-home='/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Home' finishes immediately without output
  • after installing JDK 1.8, running with --java-home=/Library/Java/JavaVirtualMachines/jdk1.8.0_45/Contents/Home produces the following error:
version = 1.5
/Users/faim/.ImageJ_3D_Viewer.props (No such file or directory)
Exception in thread "J3D-Renderer-1" java.lang.UnsatisfiedLinkError: no jogl in java.library.path
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1865)
    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
    at java.lang.System.loadLibrary(System.java:1122)
    at com.sun.opengl.impl.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:189)
    at com.sun.opengl.impl.NativeLibLoader.access$000(NativeLibLoader.java:49)
    at com.sun.opengl.impl.NativeLibLoader$DefaultAction.loadLibrary(NativeLibLoader.java:80)
    at com.sun.opengl.impl.NativeLibLoader.loadLibrary(NativeLibLoader.java:103)
    at com.sun.opengl.impl.NativeLibLoader.access$200(NativeLibLoader.java:49)
    at com.sun.opengl.impl.NativeLibLoader$1.run(NativeLibLoader.java:111)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sun.opengl.impl.NativeLibLoader.loadCore(NativeLibLoader.java:109)
    at com.sun.opengl.impl.macosx.MacOSXGLDrawableFactory.<clinit>(MacOSXGLDrawableFactory.java:53)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:108)
    at javax.media.j3d.JoglPipeline$QueryCanvas.<init>(JoglPipeline.java:9010)
    at javax.media.j3d.JoglPipeline.getBestConfiguration(JoglPipeline.java:8774)
    at javax.media.j3d.Renderer.doWork(Renderer.java:495)
    at javax.media.j3d.J3dThread.run(J3dThread.java:256)
@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Jun 23, 2015

Member

@imagejan To be clear: none of those OS X tests used the JOGL-based Java 3D 1.6 prerelease, did they?

Member

ctrueden commented Jun 23, 2015

@imagejan To be clear: none of those OS X tests used the JOGL-based Java 3D 1.6 prerelease, did they?

@imagejan

This comment has been minimized.

Show comment
Hide comment
@imagejan

imagejan Jun 23, 2015

Member

@ctrueden correct. I tested the JOGL-based Win64 bundle only on Windows, where it produced errors when Java3D 1.5 was still installed (see also http://imagej.1557.x6.nabble.com/Re-ImageJ-3D-Viewer-Java-1-8-td5012563.html), but worked well when Java3D was removed from the system Java installation. Is there a ready-to-use bundled version for OSX that I should test?

Member

imagejan commented Jun 23, 2015

@ctrueden correct. I tested the JOGL-based Win64 bundle only on Windows, where it produced errors when Java3D 1.5 was still installed (see also http://imagej.1557.x6.nabble.com/Re-ImageJ-3D-Viewer-Java-1-8-td5012563.html), but worked well when Java3D was removed from the system Java installation. Is there a ready-to-use bundled version for OSX that I should test?

@gouessej

This comment has been minimized.

Show comment
Hide comment
@gouessej

gouessej Jun 23, 2015

@imagejan You use an obsolete version of Java (even Apple advises not to use it) with an obsolete version of Java 3D based on an obsolete version of JOGL (outdated, released in 2009). Java 1.8 seems to find the Java libraries of Java3D and JOGL 1 but not its native libraries. Anyway, Java3D 1.5 should be uninstalled before using Java3D 1.6 in order to avoid conflicts, especially under OS X. We did our best to reduce the risk of name clash but it might still occur because we can't change the package names within Java3D without breaking the public API (which isn't the case in others scenegraphs).

gouessej commented Jun 23, 2015

@imagejan You use an obsolete version of Java (even Apple advises not to use it) with an obsolete version of Java 3D based on an obsolete version of JOGL (outdated, released in 2009). Java 1.8 seems to find the Java libraries of Java3D and JOGL 1 but not its native libraries. Anyway, Java3D 1.5 should be uninstalled before using Java3D 1.6 in order to avoid conflicts, especially under OS X. We did our best to reduce the risk of name clash but it might still occur because we can't change the package names within Java3D without breaking the public API (which isn't the case in others scenegraphs).

@rejsmont

This comment has been minimized.

Show comment
Hide comment
@rejsmont

rejsmont Jun 23, 2015

@gouessej @imagejan It does find native libraries when they are placed in /Library/Java/Extensions:

$ ls /Library/Java/Extensions/
gluegen-rt.jar          libgluegen-rt.jnilib        libnativewindow_awt.jnilib  libopenal.dylib
j3dcore.jar         libjoal.jnilib          libnativewindow_macosx.jnilib   vecmath.jar
j3dutils.jar            libjogl_cg.jnilib       libnewt.jnilib
joal.jar            libjogl_desktop.jnilib      libopenal.1.15.1.dylib
jogl.jar            libjogl_mobile.jnilib       libopenal.1.dylib

rejsmont commented Jun 23, 2015

@gouessej @imagejan It does find native libraries when they are placed in /Library/Java/Extensions:

$ ls /Library/Java/Extensions/
gluegen-rt.jar          libgluegen-rt.jnilib        libnativewindow_awt.jnilib  libopenal.dylib
j3dcore.jar         libjoal.jnilib          libnativewindow_macosx.jnilib   vecmath.jar
j3dutils.jar            libjogl_cg.jnilib       libnewt.jnilib
joal.jar            libjogl_desktop.jnilib      libopenal.1.15.1.dylib
jogl.jar            libjogl_mobile.jnilib       libopenal.1.dylib
@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Jun 23, 2015

Member

It does find native libraries when they are placed in /Library/Java/Extensions

@rejsmont Keep in mind that the ImageJ Launcher plays with java.ext.dirs on OS X. You can verify this by running:

/Applications/Fiji.app/Contents/MacOS/ImageJ-macosx --dry-run

And scrutinizing the -Djava.ext.dirs=... argument.

But this will become moot after we migrate away from the ImageJ Launcher later this summer.

Member

ctrueden commented Jun 23, 2015

It does find native libraries when they are placed in /Library/Java/Extensions

@rejsmont Keep in mind that the ImageJ Launcher plays with java.ext.dirs on OS X. You can verify this by running:

/Applications/Fiji.app/Contents/MacOS/ImageJ-macosx --dry-run

And scrutinizing the -Djava.ext.dirs=... argument.

But this will become moot after we migrate away from the ImageJ Launcher later this summer.

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Jun 23, 2015

Member

You use an obsolete version of Java (even Apple advises not to use it) with an obsolete version of Java 3D based on an obsolete version of JOGL (outdated, released in 2009)

@gouessej Please do not be too judgmental—we still ship Fiji with Java 1.6.0_24 (!!!). We are definitely trying to migrate away from this horribly buggy and out of date version of Java, but it takes time, and we have to be careful about backwards compatibility.

Java3D 1.5 should be uninstalled before using Java3D 1.6 in order to avoid conflicts, especially under OS X.

I fear we will need to write some code on the Java side that checks for old versions of Java 3D and warns the user about them, so that they are not blindsided by obscure error messages with no explanation. This is what I meant by "doctor" in my comment above.

Member

ctrueden commented Jun 23, 2015

You use an obsolete version of Java (even Apple advises not to use it) with an obsolete version of Java 3D based on an obsolete version of JOGL (outdated, released in 2009)

@gouessej Please do not be too judgmental—we still ship Fiji with Java 1.6.0_24 (!!!). We are definitely trying to migrate away from this horribly buggy and out of date version of Java, but it takes time, and we have to be careful about backwards compatibility.

Java3D 1.5 should be uninstalled before using Java3D 1.6 in order to avoid conflicts, especially under OS X.

I fear we will need to write some code on the Java side that checks for old versions of Java 3D and warns the user about them, so that they are not blindsided by obscure error messages with no explanation. This is what I meant by "doctor" in my comment above.

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Jun 23, 2015

Member

Is there a ready-to-use bundled version for OSX that I should test?

@imagejan Not yet. I will try to get things ready by the end of the week.

Member

ctrueden commented Jun 23, 2015

Is there a ready-to-use bundled version for OSX that I should test?

@imagejan Not yet. I will try to get things ready by the end of the week.

@rejsmont

This comment has been minimized.

Show comment
Hide comment
@rejsmont

rejsmont Jun 23, 2015

@ctrueden AFAIK it would check the directory where jni jar resides... or not?

rejsmont commented Jun 23, 2015

@ctrueden AFAIK it would check the directory where jni jar resides... or not?

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Jun 23, 2015

Member

AFAIK it would check the directory where jni jar resides... or not?

@rejsmont Sorry, I'm not sure what you're asking.

Member

ctrueden commented Jun 23, 2015

AFAIK it would check the directory where jni jar resides... or not?

@rejsmont Sorry, I'm not sure what you're asking.

@gouessej

This comment has been minimized.

Show comment
Hide comment
@gouessej

gouessej Jun 30, 2015

@ctrueden The problem is that Fiji relies on the extension mechanism, otherwise you could set java.ext.dirs to "". Maybe it's possible to create your own classloader to throw away Java3D 1.5 by using JCL as a source of inspiration: http://kamranzafar.github.com/JCL Another possibility consists in bundling OpenJDK 1.9 or a modified earlier version without any extension mechanism so that Java3D 1.5 has no chance to be loaded.

gouessej commented Jun 30, 2015

@ctrueden The problem is that Fiji relies on the extension mechanism, otherwise you could set java.ext.dirs to "". Maybe it's possible to create your own classloader to throw away Java3D 1.5 by using JCL as a source of inspiration: http://kamranzafar.github.com/JCL Another possibility consists in bundling OpenJDK 1.9 or a modified earlier version without any extension mechanism so that Java3D 1.5 has no chance to be loaded.

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Jun 30, 2015

Member

@gouessej Java 8 itself relies on the extensions mechanism for many things, including JavaScript support. (Just look in the JRE 8's lib/ext directory.) So setting java.ext.dirs to nothing is not an option.

ImageJ does use its own ClassLoader, so I suppose extending that would be a possibility.

But at least initially, I think it will be sufficient to simply warn the user about incompatible Java 3D versions found on the extensions classpath. And if users continue to suffer to much, we can explore your class loader idea.

Member

ctrueden commented Jun 30, 2015

@gouessej Java 8 itself relies on the extensions mechanism for many things, including JavaScript support. (Just look in the JRE 8's lib/ext directory.) So setting java.ext.dirs to nothing is not an option.

ImageJ does use its own ClassLoader, so I suppose extending that would be a possibility.

But at least initially, I think it will be sufficient to simply warn the user about incompatible Java 3D versions found on the extensions classpath. And if users continue to suffer to much, we can explore your class loader idea.

@gouessej

This comment has been minimized.

Show comment
Hide comment
@gouessej

gouessej Jun 30, 2015

@ctrueden Java 1.8 uses this mechanism for NIO 2 too, I know that it's a bit dangerous.

The problem is that warning the end user isn't enough when loading and running Java3D <= 1.5.2 lead to a crash. In my humble opinion, it would be better to force the loading of JOGL 2 and Java3D 1.6 very early, for example by calling GLProfile.initSingleton() as this class doesn't exist in JOGL 1.

A smarter solution would consist in using a version of Java3D with different package names. I'd like to provide such a version as it would definitely solve this trouble... until someone has the bad idea to put some craps into the directories used to load the extensions ;)

gouessej commented Jun 30, 2015

@ctrueden Java 1.8 uses this mechanism for NIO 2 too, I know that it's a bit dangerous.

The problem is that warning the end user isn't enough when loading and running Java3D <= 1.5.2 lead to a crash. In my humble opinion, it would be better to force the loading of JOGL 2 and Java3D 1.6 very early, for example by calling GLProfile.initSingleton() as this class doesn't exist in JOGL 1.

A smarter solution would consist in using a version of Java3D with different package names. I'd like to provide such a version as it would definitely solve this trouble... until someone has the bad idea to put some craps into the directories used to load the extensions ;)

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Jun 30, 2015

Member

@gouessej wrote:

A smarter solution would consist in using a version of Java3D with different package names. I'd like to provide such a version as it would definitely solve this trouble... until someone has the bad idea to put some craps into the directories used to load the extensions ;)

Yeah, we could do it very easily using the Maven Shade plugin. For example, I did it already for Jython 1.5.3: https://github.com/scijava/jython-shaded

Member

ctrueden commented Jun 30, 2015

@gouessej wrote:

A smarter solution would consist in using a version of Java3D with different package names. I'd like to provide such a version as it would definitely solve this trouble... until someone has the bad idea to put some craps into the directories used to load the extensions ;)

Yeah, we could do it very easily using the Maven Shade plugin. For example, I did it already for Jython 1.5.3: https://github.com/scijava/jython-shaded

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Nov 24, 2015

Member

There is now a "3D" update site which installs new versions of the 3D Viewer et. al which are built on Java 3D 1.6 + JOGL 2.

Enabling this update site lets the 3D Viewer function when running ImageJ with Java 8.

Once ImageJ has transitioned totally to Java 8 from Java 6 (some time in 2016), we will eliminate the 3D update site in favor of shipping its contents with Fiji by default.

Member

ctrueden commented Nov 24, 2015

There is now a "3D" update site which installs new versions of the 3D Viewer et. al which are built on Java 3D 1.6 + JOGL 2.

Enabling this update site lets the 3D Viewer function when running ImageJ with Java 8.

Once ImageJ has transitioned totally to Java 8 from Java 6 (some time in 2016), we will eliminate the 3D update site in favor of shipping its contents with Fiji by default.

@ctrueden ctrueden closed this Nov 24, 2015

@imagejan

This comment has been minimized.

Show comment
Hide comment
@imagejan

imagejan Nov 24, 2015

Member

@ctrueden Great! The "3D" update site works fine with with Java 1.8.0_66 on Windows. However it downloads jars for all platforms (gluegen-rt-natives, joal-natives, jocl-natives and jogl-all-natives each in 11 versions). Is there a way to teach the updater to automatically install only the necessary ones? (IIRC that works for ./lib/<platform>, see the FFMPEG update site; would using ./jars/<platform>/ help??)

Member

imagejan commented Nov 24, 2015

@ctrueden Great! The "3D" update site works fine with with Java 1.8.0_66 on Windows. However it downloads jars for all platforms (gluegen-rt-natives, joal-natives, jocl-natives and jogl-all-natives each in 11 versions). Is there a way to teach the updater to automatically install only the necessary ones? (IIRC that works for ./lib/<platform>, see the FFMPEG update site; would using ./jars/<platform>/ help??)

@ctrueden ctrueden referenced this issue Nov 24, 2015

Open

Switch to Java 8 #135

2 of 4 tasks complete
@tinevez

This comment has been minimized.

Show comment
Hide comment
@tinevez

tinevez Nov 25, 2015

Member

I can report some problems on Mac OSX ElCapitan.
But it '''only occurs for multi-frames''' stacks:

3D [dev] 1.6.0-scijava-2-pre11-daily-experimental daily

nFrames = 1
nFrames = 51
com.jogamp.opengl.GLException: detachAllImpl failed: FBO implementation fault, FBO[name r/w 1/1, init true, bound true, size 520x527, samples 0/8, modified true/true, depth RenderAttachment[type DEPTH, format 0x81a5, samples 0, 520x527, name 0xffffffff, obj 0x74be2048], stencil null, colorbuffer attachments: 1/8, with 1 textures: [TextureAttachment[type COLOR_TEXTURE, target GL_TEXTURE_2D, level 0, format 0x8051, 520x527, border 0, dataFormat 0x1907, dataType 0x1401; min/mag 0x2600/0x2600, wrap S/T 0x812f/0x812f; name 0xffffffff, obj 0xaed7442], null, null, null, null, null, null, null], msaa[null, hasSink false, dirty true], state FBO implementation fault, obj 0x159015f9]
at com.jogamp.opengl.FBObject.detachAllImpl(FBObject.java:2198)
at com.jogamp.opengl.FBObject.reset(FBObject.java:1139)
at org.scijava.java3d.JoglPipeline.resizeOffscreenLayer(JoglPipeline.java:6290)
at org.scijava.java3d.Canvas3D.setViewport(Canvas3D.java:4864)
at org.scijava.java3d.Renderer.doWork(Renderer.java:993)
at org.scijava.java3d.J3dThread.run(J3dThread.java:271)
Exception occurred in RenderingErrorListener:
java.lang.RuntimeException
at ij3d.ImageWindow3D$ErrorListener.errorOccurred(ImageWindow3D.java:295)
at org.scijava.java3d.VirtualUniverse.notifyRenderingErrorListeners(VirtualUniverse.java:1198)
at org.scijava.java3d.NotificationThread.processNotifications(NotificationThread.java:86)
at org.scijava.java3d.NotificationThread.run(NotificationThread.java:104)

Member

tinevez commented Nov 25, 2015

I can report some problems on Mac OSX ElCapitan.
But it '''only occurs for multi-frames''' stacks:

3D [dev] 1.6.0-scijava-2-pre11-daily-experimental daily

nFrames = 1
nFrames = 51
com.jogamp.opengl.GLException: detachAllImpl failed: FBO implementation fault, FBO[name r/w 1/1, init true, bound true, size 520x527, samples 0/8, modified true/true, depth RenderAttachment[type DEPTH, format 0x81a5, samples 0, 520x527, name 0xffffffff, obj 0x74be2048], stencil null, colorbuffer attachments: 1/8, with 1 textures: [TextureAttachment[type COLOR_TEXTURE, target GL_TEXTURE_2D, level 0, format 0x8051, 520x527, border 0, dataFormat 0x1907, dataType 0x1401; min/mag 0x2600/0x2600, wrap S/T 0x812f/0x812f; name 0xffffffff, obj 0xaed7442], null, null, null, null, null, null, null], msaa[null, hasSink false, dirty true], state FBO implementation fault, obj 0x159015f9]
at com.jogamp.opengl.FBObject.detachAllImpl(FBObject.java:2198)
at com.jogamp.opengl.FBObject.reset(FBObject.java:1139)
at org.scijava.java3d.JoglPipeline.resizeOffscreenLayer(JoglPipeline.java:6290)
at org.scijava.java3d.Canvas3D.setViewport(Canvas3D.java:4864)
at org.scijava.java3d.Renderer.doWork(Renderer.java:993)
at org.scijava.java3d.J3dThread.run(J3dThread.java:271)
Exception occurred in RenderingErrorListener:
java.lang.RuntimeException
at ij3d.ImageWindow3D$ErrorListener.errorOccurred(ImageWindow3D.java:295)
at org.scijava.java3d.VirtualUniverse.notifyRenderingErrorListeners(VirtualUniverse.java:1198)
at org.scijava.java3d.NotificationThread.processNotifications(NotificationThread.java:86)
at org.scijava.java3d.NotificationThread.run(NotificationThread.java:104)

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Nov 25, 2015

Member

@tinevez Looks like a bug in JOGL. It would be great to create an MCVE / SSCCE and submit it upstream to the JOGL team.

Member

ctrueden commented Nov 25, 2015

@tinevez Looks like a bug in JOGL. It would be great to create an MCVE / SSCCE and submit it upstream to the JOGL team.

@ctrueden

This comment has been minimized.

Show comment
Hide comment
@ctrueden

ctrueden Nov 25, 2015

Member

@imagejan Yes, we could teach the updater to ship JARs conditionally on platform, as subfolders of jars/. Care to take a crack at it? If it were me, I would start here.

Member

ctrueden commented Nov 25, 2015

@imagejan Yes, we could teach the updater to ship JARs conditionally on platform, as subfolders of jars/. Care to take a crack at it? If it were me, I would start here.

@imagejan

This comment has been minimized.

Show comment
Hide comment
@imagejan

imagejan Nov 27, 2015

Member

@ctrueden Thanks for pushing me to do this: imagej/imagej-updater#52

The more elegant solution might be to use a regex pattern to get the platform directly from the file name (to avoid the need of subfolders), but this would require more involved changes.

Member

imagejan commented Nov 27, 2015

@ctrueden Thanks for pushing me to do this: imagej/imagej-updater#52

The more elegant solution might be to use a regex pattern to get the platform directly from the file name (to avoid the need of subfolders), but this would require more involved changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment