Batik related issues in Fiji

Dear FIJI/ImageJ community,

I have noticed that FIJI can’t open SVG files anymore. Also one of my plugins which also uses batik has now lost several key svg functionalities. I could restore both tools, while also making FIJI smaller by deleting the following jar files:


i.e. all batik*.jar files except “batik-1.8.jar” from the “jar” folder

Removing those jar files does not seem to affect FIJI at all and restores FIJI svg reader. Looking inside some of these jars I noted that really a lot of classes present in “batik-1.8.jar” are duplicated in the other jar files and that is causing some weird casting errors within my plugin (when loaded in FIJI). Is there any reason to keep those jars ?

best regards,


I can confirm the issue. While the all-in-one batik-1.8.jar is served from the Fiji update site, all the others are submodules and served from the Java-8 update site.

The error I get when trying File > Import > SVG… is:

(Fiji Is Just) ImageJ 2.0.0-rc-54/1.51g; Java 1.8.0_102 [64-bit]; Windows 7 6.1; 184MB of 96000MB (<1%)
java.lang.NoClassDefFoundError: org/apache/xmlgraphics/java2d/color/NamedColorSpace
    at org.apache.batik.bridge.SVGShapeElementBridge.createShapePainter(Unknown Source)
    at org.apache.batik.bridge.SVGRectElementBridge.createShapePainter(Unknown Source)
    at org.apache.batik.bridge.SVGShapeElementBridge.buildGraphicsNode(Unknown Source)
    at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
    at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source)
    at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
    at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source)
    at Source)
    at ij.IJ.runUserPlugIn(
    at ij.IJ.runPlugIn(
    at ij.Executer.runCommand(
Caused by: java.lang.ClassNotFoundException: org.apache.xmlgraphics.java2d.color.NamedColorSpace
    at java.lang.ClassLoader.loadClass(
    at sun.misc.Launcher$AppClassLoader.loadClass(
    at java.lang.ClassLoader.loadClass(
    ... 14 more

which can also be fixed by putting xmlgraphics-commons-2.1.jar in the jars directory.

I’m not sure which are the newer versions, the all-in-one jar or the submodules, but there must be a reason why the Java-8 update site ships those. @ctrueden any insights?

1 Like

The file jars/batik-1.8.jar is an uber-JAR, which has caused many problems historically—see e.g. scijava/scijava-common#30, as well as this patch series, which actually overrides the classpath order to demote batik to the end! What a hack!

The intent was to remove the old uber-JAR in favor of the components—work which I did as part of fiji/fiji#83. I finally thought this nightmare was over, but I should have tested the SVG import feature more thoroughly. It seems that batik-bridge version 1.8 requires xmlgraphics-commons, but somehow did not declare it as a dependency in its POM. (It seems that is fixed on master, but there is no new release since 1.8 yet.)

Anyway, the correct fix here is:

I was able to import SVG files again after following the above two steps.

I cannot delete jars/batik-1.8.jar from the Fiji update site, because it would break SVG support for the legacy Java 6 installations of Fiji. (Though I am tempted to do it anyway—this is how I fixed Java compilation in the Script Editor for Java 8 installations of Fiji.)

I cannot upload xmlgraphics-commons-2.1.jar to the Java-8 update site right now, because it appears there is a problem on the server side when uploading to personal update sites via WebDAV (as evidenced by this failing Jenkins job).

I will investigate the problem of personal update site uploads, and then upload xmlgraphics-commons-2.1.jar once it is fixed.

1 Like

TL;DR: Update your Fiji and SVG import should work again!

I fixed the issue with personal update site uploads (a permissions issue introduced earlier this week).

As an aside, I updated fiji/IO to include the needed xmlgraphics-commons dependency. But it is not currently possible to make a blanket declaration in the parent POM’s dependencyManagement which forces this inclusion transitively. So I sent a message to the Maven users list asking about it.

I decided not to delete batik-1.8.jar from the Fiji update site yet, since it seems that SVG import still works while it is present—very probably thanks to Johannes’s aforementioned classpath hackery in IJ1-patcher.


Dear Jan and Curtis,

thanks a lot for your investigations. With these modifications, the svg reader works and my plugin works as well with few changes to my batik imports. As you say the presence of batik-1.8.jar in addition to all other batik jars does not seem to cause trouble, so I’m fine if you prefer to keep it. Thanks also Curtis for fixing the update sites (I’ll give it a try tomorrow).



1 Like

Dear Curtis,

the SVG import bug is back together with the last FIJI update that now includes batik 1.9. I could get it to work though simply by adding the two missing libraries:


hope you will add these to FIJI update soon, let me know.

many thanks in advance.


Thanks for following up, and sorry for breaking it again. I somehow thought the problems were addressed with batik 1.9, but no.

I added a fix for this: fiji/IO@e4da7347.

And I uploaded the resulting new dependencies (four in all) to the Java-8 update site.

So hopefully things work again for you.

FWIW, I also sent a mail to the batik-users mailing list asking about this dependency weirdness.

1 Like

Thanks for being so reactive, everything works great again. Thanks also for the fix and the report to the batik community about the dependency issue.