Feedback Needed: Bundled Java Future Directions

Hello everyone!

For some time there has been a push to update the bundled version of Java that ships with Fiji. The JetBrains runtime in particular was highly appealing due to its inclusion of JavaFX, allowing developers to explore new graphical interface options.

Our initial testing with JetBrains Java 8 revealed some issues, in particular potential deadlock/freezing problems. We saw this as an opportunity to explore shipping Java 11, as many developers are eager to build plugins that take advantage of the advances post-Java 8.

Unfortunately, the JetBrains Java 11 appears to have bundled (bizarrely) JavaFX 10, which does not play well with anything else in the JavaFX ecosystem (e.g. the ubiquitous controlsfx). So with marks against both 8 and 11, a JetBrains runtime looks to be very unlikely at this time.

Next we considered AdoptOpenJDK 11. It has performed very well in our tests - with a caveat: in Java 11, JavaFX was split out of the core Java runtime and is now distributed as a jar dependency. This means JavaFX would have to be made available in ImageJ on an update site.

So here’s where we need your feedback:

  • Would going to a Java 11 requirement break your Fiji?
  • If you’re using JavaFX, do you have functionality that is tied to JavaFX8?
  • How would you feel about transitioning update sites from Java 8 to Java 11? This would make the current Java-8 site obsolete, and likely result in two new sites: ImageJ-11 and Fiji-11.
  • In your own use, have you had to override the Java bundled with Fiji? (including using a system Java, instead of
  • Although new Fiji bundles could have these sites enabled and ship with a Java 11 runtime, existing installations would need to be manually updated to a new Java. Although it would be a considerable investment, we could look at revising the ImageJ updater to do one or both of:
    • Allow update sites to register their need for a particular Java version
    • Explicitly manage the bundled Java versions

Please let us know how these directions might affect you. If you have questions or thoughts of other directions, please share!

If you’d like to test Java 11, you can:


Hey Mark @hinerm,

great to see you back on the project! And great to see this initiative :slightly_smiling_face:

Can you by chance share a Fiji prototype with JavaFX and Java11? Or is there any other way of testing compatibility? I’m an experienced developer but I have really no idea how to approach answering this questions :slightly_smiling_face:

Thanks for your support!


1 Like

@haesleinhuepf Absolutely! I am working on a bundle right now and will link to it when complete.

There are also instructions for changing the Java version if you don’t care about JavaFX.


@haesleinhuepf - complete


Sorry to mention something that you may already be fully aware of, but I recently stumbled upon ‘jabel’ which allows software written in java9-14 to be run in a jvm8 environment, whilst still utilising functions native to the later versions:

I found it implemented in the newest ejml library (example of a successful implementation):

Not quite what you were asking here, but thought I would mention it incase it was in anyway useful.

Kind regards.

1 Like

Hi Mark,

Thank you very much for posting this about the future plans. Over the last year and a half we have developed a very substantial gui in javafx called mars-fx for sorting, tagging, filtering, OME inspection, commenting in markdown, and plotting of datasets derived from single-molecule experiments. Further explanation and documentation can be found at mars-docs. We are planning to make an announcement very soon about the software to get more input from the community and in the hopes that our work might help others.

Unfortunately, many of the libraries we used for our interface were developed for JavaFX8 and we focused our development exclusively in JDK8. I am afraid the direct jump to JDK11/JavaFX11/ControlsFX11 might break substantial parts of our GUI.

I quickly downloaded the bundle and tried an initial test and indeed is seems there might be substantial incompatibilities. The jump to JDK11 kind of caught us off guard. I was excited for the initial plan of adding JavaFX support back to Fiji but targeted for JDK8.

Overall, the most critical parts of our GUI can certainly be migrated to JDK11, and we would like to do that, but it will take us some time to complete.

So we would strongly favor a plan that involves a jump to a JDK8/JavaFX bundle now and the jump to JDK11/JavaFX11 in the near future to provide everyone more time to test and upgrade more extensively.

Please let me know if you have any suggestions for us regarding the migration and timeline…

Would there at least be an easy downgrade mechanism that we could explain to our users?


@karlduderstadt Thanks for the detailed info! :star2: This gives us clear requirements as we continue to hash out how to move forward. Right now I’m thinking we’ll need new Java-11-flavored core ImageJ and Fiji update sites (“versioned update sites” if you will), which would be used by ImageJ when it’s running Java 11, but not used if running with Java 8. Certainly we won’t do a mandatory jump to Java 11 in the near future, based on what you’ve said. But I think we should establish an optional Java-11-based path in place as soon as we can, so that projects which want to build fully on Java 11 can do so and be available via ImageJ’s updater mechanism. I’ll discuss with @hinerm next week and we’ll come back with a more refined proposal here.


Thanks for this initiative!

I’m not so familiar with Java FX, but here are the two questions I can think of, and sorry if they are naive:

  • Practically, what does this mean in terms of GUI ? Is Swing still the default library for Fiji’s GUI ? Can Swing and JavaFX be used together (drag and drop support ?)
  • We’ve been trying to integrate Fiji and QuPath from @petebankhead for quite a long a long time now in our imaging facility. And the user base for QuPath is big. Being able to make this bridge would be awesome. We’ve been successful in our attempts to compile and use Fiji inside QuPath for about two weeks… until QuPath used a more recent version of Java. I’m not sure which one (11 ? 14 ?). So I would be happy that the potential compatibility with QuPath could be taken into consideration and have the point of view of @petebankhead on this matter, if possible.

Hi, QuPath uses the latest Java available from AdoptOpenJDK. I find it works well (at least with Hotspot – I heard of issues with OpenJ9).

I believe QuPath should be compatible with Java 11, but requires Java 14 to build an executable since it is the first to contain jpackage… although it remains an incubator module, and just today I learned that changes in Java 15 have broken things slightly. However the leap from Java 8 to Java 11 is certainly the bigger one to make.

@NicoKiaru I’m not sure what change might have affected you; as far as I recall, all releases of QuPath v0.2.x use Java 14 (and the last one was over a month ago). I’d be interested in the details of how you are linking QuPath and Fiji. I have previously only done this successfully(ish) if I launched QuPath from a script within Fiji… having launched Fiji itself with Java 11.

FWIW QuPath was originally a Swing application, then rewritten for JavaFX 8, and now updated to 11+. I’ve found each major update has been well worth the temporary pain but I appreciate I didn’t have anywhere close to as many dependencies, users and developers to worry about. I think it would be great if Fiji used Java 11 and it would certainly make it easier to have it talk to QuPath, although I don’t personally find it too troublesome to keep them separated and there are likely to be other incompatibilities anyway (especially anything using JavaCPP…).


@ctrueden This sounds like a great plan to have Java-11-flavored update sites to allow for an easier transition. This would also give the opportunity to maintain Java 8 and Java 11 versions on different update sites during the transition and to allow for further testing.

I have no experience with Java 11, but from what I understand the migration from Java 8 requires minimal changes in most cases. But JavaFx is probably the exception in this regard. I created a branch to see what might be required and am still buried in errors.

Will you create a java 11 scijava pom for the Java-11-flavoured development? Or will you just bump the pom to java 11 at some point?

Maybe adding very common javafx libraries, like ControlsFX, to a common pom would help make for a smoother transition at least for javafx development. Or does this already exist somewhere and I missed it?

For now I just upgraded by overriding the following scijava.jvm lines in my pom properties:


and obviously upgrading to AdoptOpenJDK11 with javafx installed.

@petebankhead Thanks for the words of encouragement. Still having the temporary pain over here :slight_smile:


Nope, I prefer not to maintain parallel mainline branches. We’ll stick with just a single pom-scijava release line.

Thanks to @axtimwalde, we recently updated the pom-scijava to support cross-compilation from Java 9+ to target older Java versions, in a robust way, using javac’s --release option. The default target version of Java will remain Java 8, but projects wanting to target Java 11 (or other version) need only override the scijava.jvm.version property accordingly.

Each component in the SciJava component collection has a minimum required Java version. If a project tries to depend on a component requiring a minimum version of Java newer than the version they are targeting, the enforcer will fail the build.

So the question is really: at what point will any of the core libraries of SciJava/ImgLib2/ImageJ/SCIFIO update their minimum Java version from 8 to 11? Because as soon as that happens, and they propagate into the pom-scijava BOM, downstream projects will be forced also to update to Java 11. I propose that we try to complete that migration by the end of 2021. In the meantime, let’s start by establishing the dual update sites, with an Updater smart enough to act accordingly.


Ours goes to 11! Many small bugs remain, but they appear fixable.

All our jars compiled with java 8 that do not use javafx appear to ‘just work’ with java 11. However, migration of our javafx projects to java 11 required updating many javafx dependences to java 9+ or java 11 versions and updating our code to match. Our currently working pom is linked below.

I noticed that the java 11 test Fiji provided above doesn’t appear to include javafx. Or at least, I had to add the parts of javafx we use to our dependency list to get the project to compile and it seems they are copied into the jars folder. Is this the correct way of doing things? I thought they should stay in the JRE in the lib folder.

Thanks again for starting this topic @hinerm and letting everyone know about the future plans. Do you have a timeline in mind?

I still prefer adding zulu8.48.0.53-ca-fx-jdk8.0.265-macosx_x64 to the currently distributed Fiji for macos now and then migrating to java 11 later. I just downloaded a new version of Fiji and it still has the adoptopenjdk-8.jdk version that doesn’t include javafx. I assume this is because of the problems that came up with the new launcher. I tried to manually install zulu8 in my Fiji using your instructions provided here.

Unfortunately, I can’t get Fiji to use it. My Fiji always just uses the system version of java. The only thing that works for me is jdk1.8.0_172.jre. So I guess I will advise users to download that one and replace adoptopenjdk-8.jdk to get javafx running on mac in the short term. If you have any suggestions or tips here please let me know.

Switching the Java versions should definitely work… are you using the --java-home method?

Yes this is correct. I’m assuming you added org.openjfx:javafx as a dependency?

It’s not in the JRE /lib because it was split out in Java 11. So unfortunately JavaFX has to be distributed separately.

1 Like

Ahh. So what I did was download a new Fiji and remove everything in the java folder. Then I copied in zulu8.48.0.53-ca-fx-jdk8.0.265-macosx_x64. Then I opened Fiji and it uses the system java.

But if I start Fiji from the terminal and provide the --java-home with path then it does use the zulu are in the java subfolder. So when I use the -java-home path the following script

import os

print os.getenv('JAVA_HOME')



But I thought just replacing the jre in the java folder was all that was required. So does the --java-home with path always need to be specified?

Yes, I added javafx as a dependency and it works great, but does copy all the jars to the jars folder. Great, I just wanted to check if that was the correct thing to do.

Thanks a lot for the tip and feedback @hinerm

Hi @hinerm,

I did a little more investigating and discovered zulu8 is not recognised properly on mac because of the folder structure. I rearranged the folders to match the pattern I see for jdk1.8.0_172.jre and then Fiji loads the zulu jre just when opened normally without having to use the --java-home flag or the terminal to load at all. For reference here is my working folder structure:

The contents of the original zulu jre subfolder are moved to Contents/Home

So is the best short term solution for us to provide a download link to this rearranged zulu jre so users can get a working version of java 8 in Fiji that contains javafx on mac?

Oh that makes total sense. I forgot that the Azul folder structure is a bit different than other JRE’s sometimes. That’s annoying. If I remember right it’s just one folder deeper?

We could do that… we could also edit the FAQ instructions to clarify the required directory structure.

Yeah the jre is sort of one level deeper:

I haven’t tested all permutations. I just tried to mirror the folder structure I saw for jdk1.8.0_172.jre by removing most of the files in Contents/Home and replacing them with the stuff in the jre folder (as you see in my previous post that shows the working folder structure).

What is ImageJ looking for? Seems to be macosx/SOMETHING/jre/Contents/Home/ but the jre link in the default zulu folder structure doesn’t provide this pattern. I think there has to be some rearranging to make it work.

That would be great to update the FAQ. I am happy to make the changes if you point me to the right place and decide how to advise users about the folder structure issue.

For the moment, we have updated our installation instructions to explain the issue and provided a link to a copy of the working zulu with the reconfigured folder structure.

1 Like

Sorry it took me a minute, some pages had moved around in the new wiki. Here is the current FAQ.

1 Like