[ImageJ-devel] 3D Viewer vs. ClearVolume
Curtis Rueden
ctrueden at wisc.edu
Thu May 28 20:52:50 CDT 2015
Hi Florian,
Thanks for the update!
> if you know better place to discuss this then email… sure, let me
> know… I could cut and paste this mail easily into a forum type thing
> of your choice...
I have CCed the imagej-devel list, since this discussion may interest other
developers. I chose imagej-devel instead of fiji-devel because although the
3D_Viewer plugin does not ship on the core ImageJ update site, a version of
it does ship with ImageJ1. So it is not really a "Fiji-specific" plugin.
> we switched gears and looked out for methods that could bundle our
> favorite jogl and gluegen libraries in our own ueber-jar.
I hope you guys saw this page at some point:
http://imagej.net/Uber-JAR
Indeed, shading the dependencies is the most robust way of shipping two
versions of the same libraries in ImageJ right now without causing
conflicts. There are still disadvantages though, as discussed at the above
link. But if it is working for you, that is OK.
> we had to find out that on 0 of the 5 machines we could ever start the
> 3D Viewer if we used Java7 or Java8.
All Macs? If any were Windows, did you try the updated experimental bundle
I linked before?
http://curtis.imagej.net/2015-04-09-jogl-java3d/
For one thing, that bundle uses an updated version of the 3D Viewer that
never takes the liberty of trying to install Java 3D [1].
If it would be helpful, I could also prepare OS X and/or Linux versions of
such a bundle.
> Let me know what you think and if we can help in any way.
If you guys are feeling motivated, you could do more testing on various
platforms of the code changes I have done. It would be great to get the
JOGL version of Java 3D 1.6 shipping with Fiji.
I am insanely busy through at least mid June, but will try to make time to
work on this before July 1st (since after that point, I have a moratorium
on coding in order to work on papers for a while).
Regards,
Curtis
[1] https://github.com/fiji/3D_Viewer/compare/jogl-java3d
On Thu, May 28, 2015 at 3:48 AM, Florian Jug <jug at mpi-cbg.de> wrote:
> Curtis, Mark,
>
> I have some exciting and potentially also some less exciting news!
> Loic and I sat together yesterday and only went to bed far after it was
> still yesterday… ;)
> First we started playing with some classpath isolation ideas, hoping that
> the 3D Viewer und ClearVolume could happily coexist within Fiji.
> Long story short: it was hell… and our ‘lessons learned’ is that such an
> attempt is only feasible if the entire interaction between the default and
> the new classpath goes via interfaces alone.
>
> Then we switched gears and looked out for methods that could bundle our
> favorite jogl and gluegen libraries in our own ueber-jar. That sounds bad,
> doesn’t it? Yes it does… BUT: we figured that if we can at the same time
> rename the package names of jogl and gluegen + modify all our internal code
> such that only these modified packages are used we would also have our
> separate version of these libraries and could even coexist in the same
> classloader.
>
> The solutions turns out to be quite easy and uses a very nice and potent
> Maven plugin you might know: *maven-shade-plugin*
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-shade-plugin</artifactId>
> <version>2.3</version>
>
>
> <executions>
> <execution>
>
>
> <phase>package</phase>
> <goals>
> <goal>shade</goal>
> </goals>
>
>
> <configuration>
>
>
> <artifactSet>
> <includes>
> <include>net.clearvolume:cleargl</include>
> <include>net.clearvolume:clearcuda</include>
> <include>net.clearvolume:clearvolume</include>
> <include>org.jogamp.gluegen:gluegen-rt</include>
> <include>org.jogamp.jogl:jogl-all</include>
> </includes>
> </artifactSet>
>
>
> <relocations>
> <relocation>
> <pattern>javax.media.opengl</pattern>
> <shadedPattern>cv.javax.media.opengl</shadedPattern>
> </relocation>
> </relocations>
> </configuration>
>
>
> </execution>
> </execution>
> </executions>
> </plugin>
>
> The setup above is the ‘minimal’ setup we came up with late last night. We
> include our own dependencies + jogl + gluegen. From within both those
> libraries we then relocate all packages conflicting with the 3D Viewer,
> which happens to be all packages below ‘javax.media.opengl’.
>
> Status quo: on 5 out of 5 machines we tried this setup ClearVolume can
> still start (when Fiji was run with Java7 or Java8) even after the 3D
> Viewer did his pollution downloads into 'ext’.
>
> *Some potentially bad news:* we had to find out that on 0 of the 5
> machines we could ever start the 3D Viewer if we used Java7 or Java8.
> Either there is some inherent issue with Java>6, or it is because we ran
> the 3D Viewer using Java6 before, he downloaded some dependencies into some
> Java6 related path, and when later we tried to run it using Java>6 the 3D
> Viewer did not check if he has all dependencies at hand. I don’t know and
> did not yet attempt to figure that out.
>
> On a fresh fiji install I did for example this:
> 1) open fiji with regular java (1.6 on mac)
> 2) run the 3D Viewer on the mitosis 5d example dataset — he downloaded
> stuff
> 3) restart and redo — he opens the 3d viewer
> 4) restart using Java7
> 5) fail! (see below)
>
> jug at myers-mac-7:~/Repositories/GIT/imglib2/imglib2-clearvolume (master)$
> /Applications/Fiji4tests.app/Contents/MacOS/ImageJ-macosx --java-home
> /Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/
> May 28 10:38:49 myers-mac-7 ImageJ-macosx[86410] <Error>: The function
> ‘CGContextErase’ is obsolete and will be removed in an upcoming update.
> Unfortunately, this application, or a library it uses, is using this
> obsolete function, and is thereby contributing to an overall degradation of
> system performance.
> log4j:WARN No appenders could be found for logger
> (org.bushe.swing.event.EventService).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
> more info.
> [ERROR] Skipping unsupported option -port7
> version = 1.5
> Exception in thread "J3D-Renderer-1" java.lang.UnsatisfiedLinkError: no
> jogl in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)
> at java.lang.Runtime.loadLibrary0(Runtime.java:849)
> at java.lang.System.loadLibrary(System.java:1088)
> 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:191)
> at
> javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:108)
> at javax.media.j3d.JoglPipeline$QueryCanvas.<init>(JoglPipeline.java:9029)
> at
> javax.media.j3d.JoglPipeline.getBestConfiguration(JoglPipeline.java:8793)
> at javax.media.j3d.Renderer.doWork(Renderer.java:514)
> at javax.media.j3d.J3dThread.run(J3dThread.java:275)
>
> *ClearVolume is NOT installed in this Fiji yet.*
>
> Anyways… this was my coredump of today. Let me know what you think and if
> we can help in any way.
> For us it was important that you guys are informed about how ClearVolume
> deals with the version conflict of jogl at the moment.
>
> Let us know if you have questions or concerns.
>
> Cheers,
> Florian
> :)
>
> PS: if you know better place to discuss this then email… sure, let me
> know… I could cut and paste this mail easily into a forum type thing of
> your choice...
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> MPI of Molecular Cell Biology and Genetics
> Group: Gene Myers
> Pfotenhauer Strasse 108
> 01307 Dresden
> Germany
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>
>
> On 13 May 2015, at 21:01, Curtis Rueden <ctrueden at wisc.edu> wrote:
>
> Hi Florian,
>
> > a little bit of waiting time will solve all our problems. :)
>
> :-)
>
> I wish I could promise it will only be a little bit. Good news is: Mark's
> current main project is to solve the various launcher / Java 8 / OS X /
> Java 3D issues, since they are pretty much all related. Bad news is: it's
> amazing how little time we actually spend these days working on our "main
> projects"...
>
> > we should check out https://github.com/imagej/imagej/issues/120 —
> > if the mavenized jogl is all we need… that would be perfect!
>
> Just to clarify: JOGL is already Mavenized. It was the hharrison Java 3D
> fork that wasn't yet Maven based. So I did that work, and it lives in my
> fork right now:
>
> * http://github.com/ctrueden/java3d-core/compare/maven
> * http://github.com/ctrueden/java3d-utils/compare/maven
> * http://github.com/ctrueden/vecmath/compare/maven
>
> Harvey expressed interest in merging it, although he's slow to respond
> (probably he's super busy).
>
> The worst case scenario is that we move the Maven-based Java 3D fork to
> scijava org and maintain it there. But hopefully it won't come to that—the
> JOGL community seems very helpful and active so far.
>
> Regards,
> Curtis
>
>
> On Wed, May 13, 2015 at 1:51 PM, Florian Jug <jug at mpi-cbg.de> wrote:
>
>> Hi Curtis,
>>
>> thanks, that was very helpful.
>> For it means that a little bit of waiting time will solve all our
>> problems. :)
>>
>> @Loic: we should check out https://github.com/imagej/imagej/issues/120 —
>> if the mavenized jogl is all we need… that would be perfect!
>>
>> Thanks for you response Curtis,
>> Florian
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>
>> MPI of Molecular Cell Biology and Genetics
>> Group: Gene Myers
>> Pfotenhauer Strasse 108
>> 01307 Dresden
>> Germany
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>
>>
>>
>> On 13 May 2015, at 20:37, Curtis Rueden <ctrueden at wisc.edu> wrote:
>>
>> Hi Florian,
>>
>> > We would love to see the 3D Viewer and ClearVolume to coexist in Fiji.
>> > However, for this to become reality we do face the problem of
>> > mismatching dependencies. 3D Viewer depends on Java 3D >= 1.5 (Jogl
>> > 1), while ClearVolume depends on Jogl 2.2.4.
>>
>> I have recently been working on updating ImageJ to use the JOGL version
>> of Java 3D 1.6, currently in prerelease.
>>
>> This issue has the details so far:
>> https://github.com/imagej/imagej/issues/120
>>
>> In short, there is already an experimental version of Fiji that bundles
>> JOGL 2.2, the Java 3D 1.6 fork using it [1], and an updated version of the
>> 3D Viewer that removes some of the "old Java 3D" cruft.
>>
>> So far, it seems to work pretty well. The plan is to upgrade Fiji across
>> the board, so that Java 3D no longer has to be installed into the JRE, but
>> rather can ship with ImageJ just like any other dependency.
>>
>> > 1. 3D Viewer gets upgraded to the latest Java3D which is based on Jogl
>> > 2. (see https://github.com/hharrison/java3d-core) If this version
>> > turns out to be 100% compatible, which it should, then the work to
>> > upgrade should be minimal.
>>
>> Yep, right on. That's the option we're going for, and it seems to work
>> well so far. More testing needed, though.
>>
>> > 2. Since 3D Viewer downloads some dependencies on first start — we
>> > could do the same in CV + manually copy the right versions into place
>> > if a user attempts to start one of the two tools. This is ugly, but
>> > would at least allow switching between the 2 3D viewers somehow.
>>
>> Actually, I would strongly prefer that ImageJ plugins not take the
>> liberty of downloading more things outside of the ImageJ Updater paradigm.
>> It makes things really messy. I'm glad we're moving toward a version of
>> Java 3D where the 3D Viewer no longer needs to do that.
>>
>> > 3. Classloader isolation — I know what the idea is, but I have no clue
>> > how we could set this up. This would be a somewhat clean solution but…
>> > is it really what we want?
>>
>> OSGi. We've discussed it before. It's a big can of worms, which we have
>> decided to avoid indefinitely, since it makes things too complicated for
>> casual developers. Perhaps a compelling reason to use it will crop up, but
>> not so far.
>>
>> (BTW: KNIME already uses OSGi. So for people who need OSGi downstream, we
>> already have a solution for that. We just don't want to require it for the
>> core SciJava software stack.)
>>
>> Regards,
>> Curtis
>>
>> On Wed, May 13, 2015 at 12:31 PM, Florian Jug <jug at mpi-cbg.de> wrote:
>>
>>> Hi Curtis,
>>>
>>> we write directly to you and are not posting this on some mailing list
>>> or more public place because we really want to have your opinion.
>>> As soon as we come to some conclusion on this 'private channel' we are
>>> more then happy to write corresponding texts that live in the cloud and can
>>> be found by anybody interested in this topic.
>>>
>>> We would love to see the 3D Viewer and ClearVolume to coexist in Fiji.
>>> However, for this to become reality we do face the problem of mismatching
>>> dependencies.
>>> 3D Viewer depends on Java 3D >= 1.5 (Jogl 1), while ClearVolume depends
>>> on Jogl 2.2.4.
>>>
>>> We see X ways out, but we are happy to learn about other options if you
>>> see any:
>>>
>>> 1. 3D Viewer gets upgraded to the latest Java3D which is based on
>>> Jogl 2. (see https://github.com/hharrison/java3d-core) If this
>>> version turns out to be 100% compatible, which it should, then the work to
>>> upgrade should be minimal.
>>> 2. Since 3D Viewer downloads some dependencies on first start — we
>>> could do the same in CV + manually copy the right versions into place if a
>>> user attempts to start one of the two tools. This is ugly, but would at
>>> least allow switching between the 2 3D viewers somehow.
>>> 3. Classloader isolation — I know what the idea is, but I have no
>>> clue how we could set this up. This would be a somewhat clean solution but…
>>> is it really what we want?
>>>
>>>
>>> We would be very interested to get a core-dump of your thoughts on this.
>>>
>>> Thanks,
>>> Loïc and Florian
>>>
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>>
>>> MPI of Molecular Cell Biology and Genetics
>>> Group: Gene Myers
>>> Pfotenhauer Strasse 108
>>> 01307 Dresden
>>> Germany
>>>
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>>
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150528/778e9576/attachment-0001.html>
More information about the ImageJ-devel
mailing list