Fiji with Ubuntu 18.04 and OpenJDK 10 won't start up with the ImageJ-linux64 launcher

fiji
launcher
Tags: #<Tag:0x00007fa30c0f05d0> #<Tag:0x00007fa30c0f01e8>

#1

Is anyone aware of this problem? Since it affects OpenJDK 9 and later, I didn’t expect it to regress with OpenJDK 10. Is the logic to look for libjvm.so correct?

Note that OpenJDK10 is the default JRE for Ubuntu 18.04, though being packaged as 11, I expect it to be upgraded transparently to 11 in ~October.

% ./ImageJ-linux64 
Could not load Java library '/usr/lib/jvm/java-11-openjdk-amd64/lib/amd64/server/libjvm.so': /usr/lib/jvm/java-11-openjdk-amd64/lib/amd64/server/libjvm.so: cannot open shared object file: No such file or directory
Warning: falling back to System JVM
Unrecognized option: -Xincgc
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

% find /usr/lib/jvm/java-11-openjdk-amd64 -name libjvm.so
/usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so

And note this was also the system JVM.

% java -version
openjdk version "10.0.1" 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode)

% /usr/lib/jvm/java-11-openjdk-amd64/bin/java -version
openjdk version "10.0.1" 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode)

Regards,
Roger


#2

If I understand correctly, there are two issues:

  1. You are trying to run Fiji with the JRE that was shipped with Fiji, but Fiji tries to fall back to system Java because the linker fails to resolve libjvm.so
  2. System Java fails because it does not recognize the option -Xincgc. I tried to run java -Xincgc -version and I observed the same issue with Java 9 and 10, respectively. Apparently, -Xincgc was deprecated in Java 8 and subsequently removed in Java 9. It seems that -Xincgc was benefitial for single-core CPUs and, if introduced in the imagej launcher, should be removed from the launcher or only added if Java <= 8 is used. Maybe @ctrueden can comment or ping anyone who would know more about the launcher.

#3

I’m using the nojre version of Fiji; there is no JRE provided. The problem is solely that the launcher doesn’t work with the system-provided JRE as far as I can tell. It’s “falling back” to exactly the same JRE: OpenJDK 10.


#4

Please try with the latest build of the launcher, available from:

There were several issues relating to startup with Java 9+. The macOS version of Fiji already ships the updated launcher, but Linux and Windows do not yet. More testing from users would be great.


#5

Hi Curtis,

The updated launcher works to an extent. It’s still failing to find libjvm.so. The location was changed for OpenJDK9, and it looks like the launcher isn’t handling that part. Once it falls back it then starts up, albeit with a few errors.

% ./ImageJ-linux64                                                                  
Could not load Java library '/usr/lib/jvm/java-11-openjdk-amd64/lib/amd64/server/libjvm.so': /usr/lib/jvm/java-11-openjdk-amd64/lib/amd64/server/libjvm.so: cannot open shared object file: No such file or directory
Warning: falling back to System JVM
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by net.imagej.patcher.LegacyInjector (file:/home/rleigh/Downloads/Fiji.app/jars/ij1-patcher-0.12.9.jar) to method java.lang.ClassLoader.findLoadedClass(java.lang.String)
WARNING: Please consider reporting this to the maintainers of net.imagej.patcher.LegacyInjector
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
[ERROR] Exception during event handling:
        [Event] org.scijava.service.event.ServicesLoadedEvent
        context = org.scijava.Context@34399b08
        consumed = false
        [Subscriber] fiji.DefaultFijiService [priority = 0.0]
        [Method] protected void fiji.DefaultFijiService.onEvent(org.scijava.service.event.ServicesLoadedEvent)
java.lang.NoSuchMethodError: java.awt.MenuBar.getPeer()Ljava/awt/peer/MenuComponentPeer;
        at fiji.IJ_Alt_Key_Listener.getX11Opener(IJ_Alt_Key_Listener.java:98)
        at fiji.IJ_Alt_Key_Listener.getOpener(IJ_Alt_Key_Listener.java:87)
        at fiji.IJ_Alt_Key_Listener.<init>(IJ_Alt_Key_Listener.java:18)
        at fiji.DefaultFijiService.actuallyInitialize(DefaultFijiService.java:55)
        at fiji.DefaultFijiService.onEvent(DefaultFijiService.java:61)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.scijava.event.DefaultEventService$ProxySubscriber.onEvent(DefaultEventService.java:301)
        at org.scijava.event.DefaultEventService$ProxySubscriber.onEvent(DefaultEventService.java:275)
        at org.bushe.swing.event.ThreadSafeEventService.publish(ThreadSafeEventService.java:971)
        at org.scijava.event.DefaultEventBus.access$201(DefaultEventBus.java:57)
        at org.scijava.event.DefaultEventBus$2.run(DefaultEventBus.java:217)
        at org.scijava.thread.DefaultThreadService$2.run(DefaultThreadService.java:221)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
        at java.base/java.lang.Thread.run(Thread.java:844)

#6

Hmm, @stelfrich, do remember the details about your investigation into that? I thought you had fixed that…?

Those errors are known, and tracked here:


#7

I thought so too but I have completely neglected OpenJDK. The issue is in here:

We’ll have to make that heuristic smarter to also handle at the least the default directories for OpenJDK. Anyone is welcome to propose improvements, I won’t have much time to really dig into this until mid-July.

It could be as easy as adding

// Move pointer by one for OpenJDK (where the folder name start with java)
if (*p == 'a') p++;

before the check for Oracle’s Java 9.

Best,
Stefan