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 |
Description
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: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: http://imagej.net/pipermail/imagej-devel/2012-October/001250.html
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: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.