Availability of the asm-5.0.4.jar



Currently, a Fiji install with the java8 update site offers asm-4.0.jar and related asm version 4 jars under the Fiji.app/jars/ folder. I am not sure which package offers these asm jars.

In order to get the newer asm-5.0.4.jar, one has to install the SciView update site.

Would be nice to be able to get the asm-5.0.4.jar without having to install SciView.


asm-4.0.jar seems to be shipped by the ImageJ update site. As far as I can tell, asm is not managed by the parent BOM (Bill of Materials) pom-scijava, but I found it listed as a dependency of JRuby here:

Maybe updating scijava/scripting-jruby to depend on a newer version of jruby-core will help. @ctrueden might want to comment on this.


I tried it! See this branch.

The good news is that this change slims down the dependencies. There is no more ASM dependency with JRuby

Unfortunately, it seems that JRuby now behaves much differently than it did at version 1.7.12. If anyone has time to figure out why the tests fail, that would be great.


Tests pass until version of JRuby.

With higher versions in the 9.1.* range, there’s only one test failing that can be fixed with:

-		assertEquals(17, engine.get("hello"));
+		assertEquals(17L, engine.get("hello"));

So I guess it would be fine to upgrade to for now:

From 9.2.* upwards, something more seriously gets broken, as the script language doesn’t seem to get determined correctly:

NoMethodError: undefined method `getLanguageByName' for nil:NilClass
  <main> at hello.rb:3
[ERROR] null
org.jruby.embed.EvalFailedException: (NoMethodError) undefined method `getLanguageByName' for nil:NilClass
        at org.jruby.embed.internal.EmbedEvalUnitImpl.run(EmbedEvalUnitImpl.java:131)
        at org.jruby.embed.jsr223.JRubyEngine.eval(JRubyEngine.java:90)
        at org.jruby.embed.jsr223.JRubyEngine.eval(JRubyEngine.java:142)
        at org.scijava.script.ScriptModule.run(ScriptModule.java:160)
        at org.scijava.module.ModuleRunner.run(ModuleRunner.java:168)
        at org.scijava.module.ModuleRunner.call(ModuleRunner.java:127)
        at org.scijava.module.ModuleRunner.call(ModuleRunner.java:66)
        at org.scijava.thread.DefaultThreadService$3.call(DefaultThreadService.java:238)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Caused by: org.jruby.exceptions.NoMethodError: (NoMethodError) undefined method `getLanguageByName' for nil:NilClass
        at RUBY.<main>(hello.rb:3)
[ERROR] Tests run: 3, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 3.653 s <<< FAILURE! - in org.scijava.plugins.scripting.jruby.JRubyTest
[ERROR] testParameters(org.scijava.plugins.scripting.jruby.JRubyTest)  Time elapsed: 0.052 s  <<< FAILURE!
java.lang.AssertionError: expected:<Ruby> but was:<null>
        at org.scijava.plugins.scripting.jruby.JRubyTest.testParameters(JRubyTest.java:97)

[ERROR] testLocals(org.scijava.plugins.scripting.jruby.JRubyTest)  Time elapsed: 0.01 s  <<< FAILURE!
java.lang.AssertionError: expected:<17> but was:<null>
        at org.scijava.plugins.scripting.jruby.JRubyTest.testLocals(JRubyTest.java:77)


Thanks @imagejan, I squashed the commits together and merged the PR. Upgrading to for now seems OK. Would be good for people who use JRuby scripts to test a bit more before releasing and uploading, though. We should probably start a topic inviting people to do that.

We will also have a problem with layered update sites. When a dependency becomes obsolete, it cannot be marked obsolete from the ImageJ or Fiji update sites without breaking the last Java-6 version. And downstream update sites like Java-8 cannot mark it obsolete over top of upstream sites—this is a limitation of the current Updater and how it merges the db.xml.gzs.

What would address it is to dead-end the ImageJ and Fiji update sites with some logic telling users to download a new tarball, and/or to enable some different/new update sites. We have been planning to do this for some time; will discuss and plan more at the post-I2K hackathon.