Fiji crashing on startup

Hello, @frauzufall, @ctrueden

since few days I sometimes get below error when trying to start Fiji.
The only way I know how to fix it is to download a new Fiji. Is there another way?

Error while executing the main() method of class 'net.imagej.Main':
java.lang.NoClassDefFoundError: net/imagej/ImageJService
	at net.imagej.ImageJ.<init>(
	at net.imagej.Main.main(
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at net.imagej.launcher.ClassLauncher.launch(
	at net.imagej.launcher.ClassLauncher.main(
Caused by: java.lang.ClassNotFoundException: net.imagej.ImageJService
	at java.lang.ClassLoader.loadClass(
	at sun.misc.Launcher$AppClassLoader.loadClass(
	at java.lang.ClassLoader.loadClass(
	... 9 more
1 Like

Downloading a new Fiji and adding my update Site I discovered something weird:

Somehow the whole ImageJ seems to be on my update site…, which I surely did not put there on purpose.

And when I try to unselect them (i.e. not install them) as shown above it would not let me download my Site:

…indeed somehow a lot of strange things made it to my update site:

The date (20 Jan 2019) is interesting :slight_smile: It was during the Fiji Hackathon in Ostrava where I, together with @frauzufall tried to use a script to upload things to my update site. It looks like as if the script uploaded more than it should have.

@ctrueden: Is there a way to remove all items that were uploaded on that day: 2019-01-20 ? Maybe this would also resolve the crashing Fiji issues…

I can adjust update site histories manually by editing the db.xml.gz. Or you can just nuke the update site and start over, if you don’t care about the history. If there aren’t a lot of users of your site, starting over is probably easier. But if you want to avoid disrupting installations with this update site enabled, I can try the surgery approach. @Christian_Tischer What do you think?

1 Like

Thanks for offering the help!

  • I would not care about the history of the site.
  • However, there are quite some users of the site. Thus, the nuking approach would only work if the name of the reenacted site would be again EMBL-CBA. Would that in principle be possible?

However, in fact, I just now managed to

  • install a new Fiji
  • add my site (EMBL-CBA)
  • restart Fiji without crashing ( I don’t know why I did not manage yesterday )
  • remove many of the wrong uploads from my site

Thus, for now everything seems fixed (fingers crossed).

One more related question though: For some of the jars it offers me the option to “Mark as obsolete (Remove from my Site)”, for others it doesn’t. Do you happen to know the logic behind this?

Yes, that is what I meant by “nuke”: reset the history of that site.

However, if we had done that, all your existing users would then have a bunch of “locally modified” files which each user would then need to manually flag for update again—not ideal.

OK, glad to hear. I won’t worry about it for now, then. Ping back if things still seem broken.

An update site cannot remove files installed by upstream update sites. That is: update sites are purely additive: each can add new files, and/or override the versions of files from upstream, but cannot flag a file from e.g. the Java-8 site as obsolete, such that users do not receive it when your update site is enabled.

So, perhaps what you are observing here is that new files you added can be marked as obsolete, but files whose versions you overrode from upstream cannot be fully removed—only marked as “unshadowing”?

1 Like

Thanks for the answers!

One last question: Do you know what could be the actual reason for the error message that I got?

Error while executing the main() method of class 'net.imagej.Main': 
java.lang.NoClassDefFoundError: net/imagej/ImageJService at net.imagej.ImageJ.<init>
( at net.imagej.Main.main(

Firstly, be sure to check for “Caused by” traces beneath the trace in question, since class loading errors sometimes chain back through several traces in a “domino effect” of dependency loading.

If the trace indeed ends at net.imagej.ImageJService: that class is part of imagej-common. You can search for classes using’s classname search feature.

Is jars/imagej-common-x.y.z.jar present in your installation? If so: at what version? If the version is very old, that class (net.imagej.ImageJService) might not exist in the JAR file, which would also explain the error. You can check whether the class exists using this invocation:

$ jar tf jars/imagej-common-0.28.2.jar | grep ImageJService

And if you crave more details, you can dump the class’s structure using:

$ javap -cp jars/imagej-common-0.28.2.jar net.imagej.ImageJService
Compiled from ""
public interface net.imagej.ImageJService extends org.scijava.service.Service {

If the JAR file is missing or outdated, one way to repair the installation is to copy an imagej-common JAR from a working Fiji installation. You might end up with a version mismatch (typically a NoSuchMethodError), or a new ClassNotFoundException (in which case, repeat the process with the next missing class), or a working installation, depending how deep the problems go.

1 Like