Java3D Issue: BoneJ with latest Fiji version - Problem solved

Dear all,

after some years not updating Fiji or following its development, I updated Fiji recently to the latest version.

I found out - without digging too deep into this topic - that the Fiji
people obviously no longer support Java3D like they did with older

Therefore the latest 3d-viewer plugin no longer automatically installs the Java3D
libraries which are a prerequisit for BoneJ.

With a bit of trial and error I figured out how to overcome this limit
for me. Thanks to an older version of the 3d-viewer-plugin and the Java3D archive
maintained by Bene Schmid the missing libraries were installed.

I thought it might be helpful for other users who will face this problem
sooner or later, too:

One can download the Java3D libraries here:

And put them into these directories:

./Fiji/java/linux-amd64/jdk1.8.0_66/jre/lib/ext: j3dcore.jar
./Fiji/java/linux-amd64/jdk1.8.0_66/jre/lib/ext: j3dutils.jar
./Fiji/java/linux-amd64/jdk1.8.0_66/jre/lib/ext: vecmath.jar

Afterwards BoneJ works again.



1 Like

Hi @Scrivello,

As discussed off-list, Fiji does still support Java3D, via the SciJava fork of it, which forces an upgrade to at least Java 7:

That’s kind of a pain for BoneJ1 because it uses (at least) vecmath from Java3D, and attempting to support legacy ImageJ and current ImageJ2, along with legacy and current Java versions is a bit tricky. BoneJ2 will use the bundled goodness of ImageJ2 so this is not a problem in the future. I’m reluctant to force users to do tons of updates to a working system, or force them to stay with legacy ImageJ - and BoneJ1 will be current for a couple of years yet. Forcing all BoneJ users to stay on ImageJ1 is unreasonable, as is forcing all Fiji users to not use BoneJ (or forcing us to migrate users who do not want to, to a newer ImageJ & Java codebase).

One way to get around it is for users to install Java3D v1.5 manually into their Java, as you have described, with users being responsible for identifying their particular system and downloading the right bundle. Another way is for BoneJ to take over the Java3D autoinstalling that ImageJ 3D Viewer used to handle.

Java3D 1.5 is still available for download for Mac OS X, Linux 64-bit and 32-bit, and Windows 64-bit and 32-bit Java runtime environments. Mac users may additionally need JOGL universal or PPC bundles.

@Scrivello - I just tried to reproduce this on a fresh installation of ImageJ2 + Fiji update site and running the 3D Viewer menu command resulted in the auto-installer running (which is the usual behaviour). Maybe something else was going on?

Edit: it was - the reported behaviour occurs only when the “Java-8” update site is activated.

Dear Michael,

maybe I should have mentioned that I use Linux.

I reproduced a minute ago the problem which I mentioned in my post.

I installed Fiji which I downloaded today. I let Fiji do all updates. Then I started 3D-Viewer. In a console window the following message was displayed:

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

Java3D was not installed.

Then I downloaded BoneJ from your website, today, installed it in the plugins directory and could reproduce the missing Java3D problem from above.

I did not read all the background information concerning Java3D, SciJava, ImageJ and ImageJ2 sofar as the information is disseminated over to many different sources of information. Maybe someone takes the time to write a summary which is easy to find on this topic. I have not time to follow all the developer thread discussions.

I wrote some plugins myself which use Java3d (an image registration plugin for 2.5 D data). I am afraid that I will have to search all the necessary information in the near future myself if I want to continue to use this plugin with ImageJ2.

In summary:

My error report above is confirmed at least for my Linux installation.



Dear Karl-Heinz,

Thank you for listing the steps to reproduce. I have reproduced it too, under slightly different conditions.

It is relatively trivial to incorporate the Java3D check class from the old 3D Viewer into your plugins. I did this for BoneJ1 already, on its testing branch. This might be an adequate ‘wound dressing’ for those of us with a need to preserve forwards and backwards compatibility, at least temporarily.

Also - your Scanco file importer code that is distributed in BoneJ will likely get ported to BoneJ2 (for use in ImageJ2) by @rimadoma, so please do not expend energy on that - we can take care of that for you.


The easiest way to use Fiji with BoneJ right now is to download a Life-Line version of Fiji and then fully update it. This will give you a fully updated version of Fiji bundled with Java 6, without the Java-8 update site enabled. Then, as @mdoube says, you should be good to go. The auto-installer should work, giving you Java 3D 1.5 into your installation of Java 6 as desired. (Or: you can install Java 3D 1.5 into your Java 6 installation manually yourself, and the 3D Viewer should successfully find it.)

In my experience, Java 3D 1.5 does not work with Java 8 (at least on certain platforms). So we had no choice but to switch to JogAmp’s Java 3D 1.6 to make the 3D Viewer et. al continue working with Java 8.

You could also try installing Java 3D 1.5 into Java 8 on Linux—I did not test this—but I wouldn’t be surprised if it fails with an exception.

We have invested a large amount of time in continuing to support Java 3D, at least insofar as it is possible to do so with Java 8. See these threads for further details:

Good idea. I actually really want to do this, but am unsure where on the wiki would be best. It needs to cover the current situation with respect to Java 6 vs. Java 8, as well as the ramifications there regarding Java 3D. The current situation is basically:

  • If you download vanilla ImageJ2 from you get a “Java 6” version from February—i.e., no Java-8 update site.
  • If you download the latest Fiji from you get the newest “Java 8” version—i.e., with Java-8 update site. This includes the Java 3D 1.6 (SciJava fork) along with all Fiji plugins (except for TrakEM2) updated to work with it.
  • If you download a Life-Line version of Fiji and fully update it, you’ll have the newest (probably the final) “Java 6” version including the latest Java-6-compatible plugin versions. No Java 3D until you run the 3D Viewer for the first time and it gets auto-installed. Those plugin versions are frozen: we are in the process of migrating everything to Java 8, and are only uploading new versions of everything to the Java-8 update site now, to avoid breaking the stable Java-6 versions of everything.

Ultimately, we will push all the Java-8 stuff back to the core ImageJ and Fiji sites. But not until we add a launch check that verifies your version of Java is new enough—and if not, tells you how to upgrade it. We will definitely archive the final Java-6-compatible version of Fiji when we complete that transition.

1 Like

Dear ctrueden,

thank you very much for taking your time to look into this problem. You comments are very helpful for me.

However, I have to confess that I would have assumed that the link under " Download Fiji for your OS " would point to a distribution which works in any case, as I just wanted to use Fiji out of the box. This is usually also the way how I recommend my students to start with Fiji. The term “life-line” is new to me. Sometimes it is hard to understand these terms if you are not continuously involved with the development of a program. Being a no-native English speaker I did not instantly understand what is meant with “life-line”. Thanks to your hints I make progress to understand all these details concerning Java 6, Java 8, life-line etc.

Thank you also for providing the links with additional information. I will follow the links as soon as I find more time. I understand that it is a lot of work to consider all aspects of the development of software like Fiji.

I would like to motivate you to write a summary about the transition from Java3d to SciJava. It would make it much easier to get started with my own plugins again.

Finally I would like to add a few words as feedback:

  1. I like Fiji very much as I have all plugins which I need in one distribution.
  2. I like ImageJ1 a lot, too, as it was very easy for me as a medical hobby programmer to get started with my own plugins.
  3. I get more and more stressed by all the changes with the current developments (ImageJ2, Maven etc.). It was so nice several years ago just to use Netbeans, add a few jar files and one was close to a self-written plugin. I get more and more the feeling that you have to be a hard-core coder to keep up with all the changes in Fiji since than.

I had a very very short look at the Fiji github page as I wanted to download the latest ImageJ source code to recompile all my self-written plugins. But I quit this effort rather frustrated when I saw all the different projects (more than 8 pages) which I did no longer understand intuitively. Yes, I tried to read. But a lot of documentation which I found without really digging too deep is rather dated already. I miss the single “mega archive” where I can get all at once with all dependencies working out of the box.

I have the feeling that the learning curve to develop own small plugins for the current Fiji is much steeper nowadays.

Anyway, Fiji and ImageJ are unrivalled programs. I like to work with them. I like the excellent support from the community. I admire what you all achieve. I hope that I find the faith to throw myself on the current code again in the near future.

All the best.



You are quite right:
java.lang.ClassCastException: org.scijava.vecmath.Point3f cannot be cast to javax.vecmath.Point3f

Which happens because BoneJ1 asks the 3D Viewer for the list of Point3fs that make up the surface mesh. Because the library has changed, Java refuses to treat the new Point3f as an old Point3f.

I also get a:
There was a problem with the class customnode.CustomTriangleMesh which can be found here: /home/mdoube/ java.lang.NoSuchMethodError: customnode.CustomTriangleMesh.<init>(Ljava/util/List;Ljavax/vecmath/Color3f;F)V at org.doube.bonej.StructureModelIndex.hildRueg( at at ij.IJ.runUserPlugIn( at ij.IJ.runPlugIn( at ij.Executer.runCommand( at at

Which I interpret more generally as meaning that BoneJ1 users must not enable the Java-8 update site, because drift in dependencies (3D Viewer and Java 3D) will not be supported.

I concur that the the easiest way to use ImageJ2 with BoneJ1 is to download the All Platforms version of ImageJ2, then turn on the Fiji update site to get the 3D Viewer, and add BoneJ_.jar as usual. I missed the download link at first - it’s the great big button at the top of the download page so I added a text link to the intro text on the Wiki as a hint for those of us who are maybe more text focussed.

I’ll add a check to BoneJ1 to avoid this version collision and to remind users to keep the Java-8 update site disabled until BoneJ2.

True. But what I meant by my comment above was that if you install Java 3D 1.5 into Java 8, and then run Fiji without the Java-8 update site enabled, it still will not work, even though the plugins want javax.vecmath and com.sun.j3d classes, and indeed those are what Java 3D 1.5 provides. In my experience, this configuration produces the following exception within the 3D Viewer:

Exception occurred in RenderingErrorListener:
	at ij3d.ImageWindow3D$ErrorListener.errorOccurred(

See also this forum thread for related discussion.




It works fine here: vanilla ImageJ2 + Fiji update site on Java 1.8 with Java3D 1.5 installed and used by 3D Viewer (all on Ubuntu 14.04 and nvidia GTX 680, if that is relevant). Java-8 update site disabled (although, it had previously been enabled to reproduce the exceptions above).

1 Like

Those downloads do indeed work “out of the box” with no additional configuration. If you notice otherwise, please do let us know.

What you cannot necessarily do, though, is install old extensions such as BoneJ1 and expect them to work with the latest version. While we have historically tried very, very hard to maintain backwards compatibility forever across the entire ecosystem of existing ImageJ plugins, in the case of Java 3D + Java 8 it simply became impossible to do so.

The term “Life-Line” was chosen by the previous maintainer of Fiji, who is also not a native English speaker. If you have a suggestion for terminology that would communicate the ideas more clearly—that these are old, stable versions of Fiji for use when the latest has some issue with your workflows—please feel welcome to edit the wiki to describe things in a better way. It would be most appreciated!

I am very glad to hear that these programs are useful to you!

I am sorry the current situation is a source of stress for you. Please feel free to use this forum to get your questions and concerns answered quickly. We very much want to help you minimize that stress!

If you describe what you want to accomplish, we can point you toward the simplest way of achieving it.

When you see outdated documentation—especially a page that you wish was current—please complain loudly. Then someone might have time to update it. Or at least give tips on how you could go about doing so.

The top-level source for ImageJ is at:

The top-level source for Fiji is at:

When you build, these projects will link in all the plugins as precompiled JAR dependencies. In NetBeans, it should be as simple as importing the source from the Git repository. You can use any Maven-based project you want with that approach, not just ImageJ. So e.g. you can import fiji/fiji that way, or an individual plugin such as fiji/AnalyzeSkeleton.

Start from imagej/minimal-ij1-plugin, edit the pom.xml to your liking, and then import into NetBeans. Then edit the sources as normal, and you are good to go.

You can also write scripts and plugins in the Script Editor, which is intended to be a beginner-friendly development approach (as compared to IDEs, which many scientists have complained are too complicated for their needs).

Again, we are here to help, should you have the time and energy to invest.

Indeed, I have also seen other reports of this configuration working on Linux.

But on OS X 10.11, one receives:

Exception in thread "J3D-Renderer-1" java.lang.UnsatisfiedLinkError: no jogl in java.library.path
	at java.lang.ClassLoader.loadLibrary(
	at java.lang.Runtime.loadLibrary0(
	at java.lang.System.loadLibrary(
	at com.sun.opengl.impl.NativeLibLoader.loadLibraryInternal(
	at com.sun.opengl.impl.NativeLibLoader.access$000(
	at com.sun.opengl.impl.NativeLibLoader$DefaultAction.loadLibrary(
	at com.sun.opengl.impl.NativeLibLoader.loadLibrary(
	at com.sun.opengl.impl.NativeLibLoader.access$200(
	at com.sun.opengl.impl.NativeLibLoader$
	at Method)
	at com.sun.opengl.impl.NativeLibLoader.loadCore(
	at com.sun.opengl.impl.macosx.MacOSXGLDrawableFactory.<clinit>(
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(

And on Windows 7 64-bit, the error is:

Exception occurred in RenderingErrorListener:
	at ij3d.ImageWindow3D$ErrorListener.errorOccurred(


That’s unexpected - JOGL is meant to be installed by the old 3D Viewer, so it should not be missing, though I guess it could be clobbered/colliding with something else.

That one is a bit more obscure. Looks like the safest / easiest advice for BoneJ1 users is to stick with Java 6 and try Java 8 only with an expectation that it might not work (especially on OSes other than GNU/Linux).

Our basic idea is that I (with the minimal personal resources I have to do it) keep BoneJ1 maintained on a usable bug-fix level, without major changes to its build and distribution model. BoneJ2 will take over eventually, using the new features of ImageJ2, Java8, updater, Maven, etc. For users that means that BoneJ1 will continue to run and behave like it has for the last 5 years, but on progressively outdated infrastructure (Java 6, manually installed bundled Jar, Java3D 1.5, no update site, old 3D Viewer). @hinerm made a nice transition to Maven for BoneJ, which @rimadoma will use as a starting point to move legacy BoneJ1 code over to BoneJ2, so that users of ImageJ2 and Java 8 can just click on the BoneJ update site (when we are ready to ship stable v2.0 code) and get all the stuff.

Dear all,

I would like to start by thanking all who have contributed to the great tool that is BoneJ.
I’m sorry to bring this issue again here, especially since it is marked as solved, but I cannot make 3D viewer work with BoneJ (on my MAC OS X 10.11). I recently encountered the problem (probably after an update) that 3D viewer was not working at all in Fiji (due to the absent ‘Jogl’, see error message on OS X posted above by ctrueden). But after updating all plugins, 3D viewer does work again when used ‘on its own’ (I mean directly from the plugin menu).
However, when a 3D representation is asked by BoneJ ( e.g., checking the option in Anisotropy), I get the following error:

(Fiji Is Just) ImageJ 2.0.0-rc-46/1.50g; Java 1.8.0_73 [64-bit]; Mac OS X 10.11.4; 1061MB of 5898MB (17%)

at java.util.ArrayList.toArray(
at customnode.CustomPointMesh.createGeometry(
at customnode.CustomMesh.update(
at customnode.CustomMesh.(
at customnode.CustomMesh.(
at customnode.CustomPointMesh.(
at org.doube.bonej.Anisotropy.plotPoints3D(
at ij.IJ.runUserPlugIn(
at ij.IJ.runPlugIn(
at ij.Executer.runCommand(

All the best,

@Eli: see the post by @ctrueden above

BoneJ1 is going to stick with Java 6. To get it to work on your Mac, please follow the instructions above. I see that your Fiji is currently using Java 8 ; this is what is causing your problem. We are in the middle of updating BoneJ so that it will work on Java 8, and will notify everyone when that’s done. In the meantime, to use BoneJ on Windows and Mac Fiji must be running in a Java 6 JRE.

1 Like

@mdoube : Thanks a lot for your answer, sorry for the redundancy with the previous post. I wish you to keep up the good work then!


@mdoube @rimadoma What do you think about making platform-specific Fiji+BoneJ downloads available at And adding BoneJ to the distributions section? (Tangentially: does BoneJ have a logo? :slight_smile:)

If we did this, users could get a working version of BoneJ with no hassles—except on OS X, where you would still need to reinstall Java 6. But it would still be easier than the process we outlined above.

1 Like

As previously discussed, we (mainly @rimadoma) plan to do an ImageJ2+BoneJ2 distribution. BoneJ1 will stay as it is, with minor bugfixes and support releases (by me) until users can reasonably transition to BoneJ2.

It’s important that @rimadoma stays focussed on delivering BoneJ2-related engineering rather than getting distracted by supporting legacy users, which I can do with minimal input because I know it inside-out. We’re moving towards a situation when BoneJ2 is ready for users that they will simply turn on a BoneJ update site in ImageJ2, and all the dependencies will get installed. Until then, the old installation route will stand. Having a transition situation is just confusing for everyone (including us).

For BoneJ1, I’ve used this:

For BoneJ2, I was considering something that continues the theme and mentioned it recently to @rimadoma.

I understand that. I was not proposing to make any changes to the code—just to create Jenkins jobs that go through the steps we outlined above (start from “Java 6” version of Fiji, bring it fully up to date, add BoneJ JAR file) and then post the archives. That way people can just “download and go.” The point would be to cut down on these sorts of support questions in the future—or at least make answering them more straightforward, by replying with the download link.