NOTICE! This is a static HTML version of a legacy Fiji BugZilla bug.

The Fiji project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Bug 213 - JRuby Interpreter fails to start if any interpreter has been started beforehand
JRuby Interpreter fails to start if any interpreter has been started beforehand
Status: RESOLVED FIXED
Product: Fiji
Classification: Unclassified
Component: Plugins
unspecified
PC Linux
: P4 normal
Assigned To: Johannes Schindelin
Depends on:
Blocks:
 
Reported: 2010-08-10 17:45 CDT by Mark Longair
Modified: 2011-03-23 18:20 CDT
1 user (show)

See Also:

Description Mark Longair 2010-08-10 17:45:37 CDT
(I'll have to look into this further when I have time, but I think it's best to have it in the bug tracker anyway, in case anyone has the same problem or is inspired to work on it...)

To reproduce this, start any interpreter (e.g. Jython Interpreter, JRuby Interpreter, Clojure Interpreter).  Then close it again.  Now start JRuby Interpreter, and you'll get an error box with:

  Plugin JRuby.JRuby_Interpreter did not find required class: org/jruby/runtime/callback/FastInvocationCallback

Information about your version of Java - this information is useful for the Fiji developers:
  os.arch => amd64
  os.name => Linux
  os.version => 2.6.32-24-generic
  java.version => 1.6.0_20
  java.vendor => Sun Microsystems Inc.
  java.runtime.name => Java(TM) SE Runtime Environment
  java.runtime.version => 1.6.0_20-b02
  java.vm.name => Java HotSpot(TM) 64-Bit Server VM
  java.vm.version => 16.3-b01
  java.vm.vendor => Sun Microsystems Inc.
  java.vm.info => mixed mode
  java.awt.graphicsenv => sun.awt.X11GraphicsEnvironment
  java.specification.name => Java Platform API Specification
  java.specification.version => 1.6
  sun.cpu.endian => little
  sun.desktop => gnome
  file.separator => /
Comment 1 Johannes Schindelin 2010-08-14 21:16:11 CDT
I _think_ that this has nothing to do with a previously invoked interpreter, but rather something with the way ImageJ handles updates: a new classloader is instantiated, and we require that to be a FijiClassLoader (because ImageJ's PluginClassLoader has no idea about jars/).

If I am correct, then IJ.getClassLoader() will return an instance of PluginClassLoader, not of FijiClassLoader.

You can test this by running this little macro:

     eval("script", "IJ.log('' + IJ.getClassLoader());");

(This requires Java6, because earlier Java requires jars/js.jar, which is not found if the classloader is not a FijiClassLoader).
Comment 2 Johannes Schindelin 2010-08-14 21:19:24 CDT
Clarification: by "updates" I meant "menu updates", AKA Help>Refresh Menus. And such a menu update might be triggered by the Clojure Interpreter.

There is a tiny chance that me recent work on the refresh code helps, if that is not the case, we will have to patch ImageJA a bit more to try to instantiate a FijiClassLoader and fall back to the PluginClassLoader.
Comment 3 Johannes Schindelin 2011-03-23 16:49:13 CDT
I just fixed this bug.

But now I get this instead:

<script>:1: undefined method `include_class' for main:Object (NoMethodError)
...internal jruby stack elided...

This is probably related to the "import all IJ and TrakEM2 and java.lang classes" feature I added recently.

Will keep you posted.
Comment 4 Johannes Schindelin 2011-03-23 18:20:35 CDT
Fixed! It was a matter of importAll() being called too early.