NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #1548 (closed defect: fixed)

Opened 2012-10-23T14:48:05-05:00

Last modified 2014-05-06T09:06:34-05:00

Example beanshell script errors out

Reported by: bdezonia Owned by: dscho
Priority: major Milestone: imagej2-b9-rois
Component: Scripting Version:
Severity: serious Keywords:
Cc: sapristi@… Blocked By:
Blocking: #1516


In the imagej dev mailing list Albert Cardona reported the following in regards to beta 5:

This beanshell script:

import ij.IJ;
IJ.log("hello world");

... fails to execute with the error:

Caused by: Sourced file: null : Error in method invocation: Method
log( java.lang.String ) not found in class'imagej.ImageJ' : at Line: 2
: in file: <unknown file> : IJ .log ( "hi" )

... which seems to indicate that the "log" method is not found in the
class where it is invoked.

Change History

comment:1 Changed 2012-10-23T14:48:16-05:00 by bdezonia

  • Cc sapristi@… added

comment:2 Changed 2012-10-24T08:34:49-05:00 by dscho

This is expected behavior, as "IJ" is referring to the current imagej.ImageJ instance (called "context").

We might consider adding the log() method and a variance of the run() methods, by wrapping the context in an adapter that delegates the imagej.ImageJ methods and adds convenience functions. But it would be a good idea to have a good plan what methods need to be added first.

comment:3 Changed 2012-10-24T15:17:49-05:00 by bdezonia

Note that Albert added this to his post on the mailing list:

By the way I wanted to comment on the issue about the beanshell
interpreter but the trac system is not sending me a password.

The comment is short: if in beanshell one writes "import ij.IJ;" one
expects that the IJ class of the ij.jar is imported. No magic should
happen. And then IJ.log will open the old log from IJ1. If one wants a
new log surely IJ2 has a new way of echoing to the screen.

comment:4 Changed 2012-10-24T17:30:47-05:00 by bdezonia

Johannes replied in the imagej-devel list. See the originating thread for details:

comment:5 Changed 2013-03-19T11:22:57-05:00 by bdezonia

  • Status changed from new to reviewing

dscho, please associated with some feature ticket

comment:6 Changed 2013-03-19T14:23:53-05:00 by dscho

  • Blocking 1516 added

comment:7 Changed 2013-06-07T16:39:44-05:00 by curtis

  • Owner changed from dscho to curtis
  • Status changed from reviewing to accepted
  • Milestone changed from imagej2-b7-ndim-data to imagej2-b9-rois

As discussed on the mailing list, the problem is that unfortunately, the current scripting framework uses "IJ" as a pointer to the IJ2 context. Personally, I think we need to change the name to something else, but agree with Dscho that choosing a name is difficult. (We don't want to use "ij2" because it will not always be ImageJ 2.x.x; ultimately there will be an ImageJ 3.0.0, etc.) Perhaps "ijc" or similar would be good enough, and not clash.

comment:8 Changed 2013-06-07T16:39:52-05:00 by curtis

  • Owner changed from curtis to dscho
  • Status changed from accepted to assigned

comment:9 Changed 2013-06-10T12:22:16-05:00 by dscho

The simplest trick (which I would be totally in favor of) would be to make IJ a proxy class that proxies the methods of ij.IJ to ij.IJ (as long as we do not have drop-in replacements).

comment:10 Changed 2014-05-06T09:06:34-05:00 by curtis

  • Status changed from assigned to closed
  • Resolution set to fixed

The IJ2 scripting approach is now to annotate desired services and other input & output parameters using "@" style annotations in comments at the top of the script. As such, the string "IJ" is no longer reserved for the ImageJ2 context, and the script above works as-is.