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 Fiji.app/java/)
  • 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:

10 Likes

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!

Cheers,
Robert

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.

3 Likes

@haesleinhuepf - complete

2 Likes

Hi,
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?

Thanks,
Karl

@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.

2 Likes

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.
3 Likes

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…).

3 Likes

@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:

<scijava.jvm.version>11</scijava.jvm.version>
<scijava.jvm.test.version>11</scijava.jvm.test.version>
<scijava.jvm.build.version>11</scijava.jvm.build.version>

and obviously upgrading to AdoptOpenJDK11 with javafx installed.

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

3 Likes

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.

2 Likes