ctrueden
commented
6 years ago Thanks for the report, @Meyenhofer. I spent a few minutes digging yesterday, and here is what I found so far:
-
The new
javassist-3.23.1-GA.jarhas a new bug preventing successful generation of aCannotCompileExceptionwhen attempting to patch ImageJ1. Hence theNullPointerException:Caused by: java.lang.NullPointerException at javassist.CannotCompileException.<init>(CannotCompileException.java:77)This bug is already reported (jboss-javassist/javassist#209) and fixed (jboss-javassist/javassist@a3d1aa25133c2ec473e9b3ebe2bfa5b4ebe5759e) upstream. Until a new Javassist release is cut, I reverted to version 3.22.0-GA in the BOM (scijava/pom-scijava@ac4809579d66fe5b76073ccf887b4d93fc41a690).
-
Then the real error emerges, which is:
Caused by: java.lang.RuntimeException: Cannot load class: ij.ImagePlus (loader: sun.misc.Launcher$AppClassLoader@18b4aac2) It appears that this class was already defined in the class loader! Please make sure that you initialize the LegacyService before using any ImageJ 1.x class.So something has a direct reference to an ImageJ1 class, and that something gets loaded as part of the ImageJ2 context creation, hosing the whole system. This is borne out by the verbose error message when launching ImageJ with imagej-legacy instrumentation in place:
Legacy Java agent initialized net.imagej.patcher.JavaAgent$ImageJ1ClassLoadedPrematurely: Loading ij/ImagePlus into sun.misc.Launcher$AppClassLoader@18b4aac2! at org.scijava.util.ClassUtils.cacheAnnotatedObjects(ClassUtils.java:291) at org.scijava.util.ClassUtils.getAnnotatedMethods(ClassUtils.java:138) at org.scijava.util.ClassUtils.getAnnotatedMethods(ClassUtils.java:111) at org.scijava.service.ServiceHelper.createServiceRecursively(ServiceHelper.java:349) at org.scijava.service.ServiceHelper.createExactService(ServiceHelper.java:270) at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:232) at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:195) at org.scijava.service.ServiceHelper.loadServices(ServiceHelper.java:167) at org.scijava.Context.<init>(Context.java:281) at org.scijava.Context.<init>(Context.java:237) at org.scijava.Context.<init>(Context.java:177) at org.scijava.Context.<init>(Context.java:163) at net.imagej.ImageJ.<init>(ImageJ.java:77) at net.imagej.Main.main(Main.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at net.imagej.launcher.ClassLauncher.launch(ClassLauncher.java:279) at net.imagej.launcher.ClassLauncher.run(ClassLauncher.java:186) at net.imagej.launcher.ClassLauncher.main(ClassLauncher.java:77) net.imagej.patcher.JavaAgent$ImageJ1ClassLoadedPrematurely: Loading ij/measure/Measurements into sun.misc.Launcher$AppClassLoader@18b4aac2! at org.scijava.util.ClassUtils.cacheAnnotatedObjects(ClassUtils.java:291) ... net.imagej.patcher.JavaAgent$ImageJ1ClassLoadedPrematurely: Loading ij/gui/Overlay into sun.misc.Launcher$AppClassLoader@18b4aac2! at org.scijava.util.ClassUtils.cacheAnnotatedObjects(ClassUtils.java:291) ...Unfortunately, the detailed error message still does not tell us which class is loading an IJ1 class prematurely. But it may be possible to see this more easily with
-verboseto the JVM. I will keep investigating.
fmeyenhofer
On Mac OsX with a fresh Fiji.app (without JRE, local Java version 1.8.0_121): 1) launch Fiji.app 2) Help > Update ... 3) (in the update dialog) Manage update sites 4) check OMERO 5.4 5) close Fiji.app
After this the application will not start again. When running ImageJ-macosx from the command line, I get the following output: