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 921 - Script editor attempts to parse @ in /* comments */ as parameters
Script editor attempts to parse @ in /* comments */ as parameters
Status: RESOLVED LATER
Product: ImageJ
Classification: Unclassified
Component: SCIFIO
unspecified
All All
: P5 normal
Assigned To: ImageJ Bugs Mailing List
Depends on:
Blocks:
 
Reported: 2014-08-28 18:16 CDT by Stephan Saalfeld
Modified: 2015-04-06 15:49 CDT
4 users (show)

See Also:

Description Stephan Saalfeld 2014-08-28 18:16:13 CDT
A Beanshell script that starts with a documenting comment:

/**
 * 
 * @author Monkey
 */

triggers an error message:

Started joint-lens-samples.bsh at Thu Aug 28 19:09:07 EDT 2014
Parse error at line 1, column 2.  Encountered: *
	at bsh.Parser.generateParseException(Unknown Source)
	at bsh.Parser.jj_consume_token(Unknown Source)
	at bsh.Parser.Line(Unknown Source)
	at bsh.Interpreter.Line(Unknown Source)
	at bsh.Interpreter.eval(Unknown Source)
	at org.scijava.plugins.scripting.beanshell.BeanshellScriptEngine.eval(BeanshellScriptEngine.java:80)
	at org.scijava.script.ScriptModule.run(ScriptModule.java:172)
	at org.scijava.module.ModuleRunner.run(ModuleRunner.java:167)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:126)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:65)
	at org.scijava.thread.DefaultThreadService$2.call(DefaultThreadService.java:164)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)

I suspect that the method to parse annotation style parameters is not robust against comments.  Removing the comment enables the script to run.  The Beanshell Interpreter runs it with the comment.
Comment 1 Johannes Schindelin 2014-08-29 03:32:29 CDT
Since Javadoc makes only sense for Java source code, I am tempted to mark this as a WONTFIX: the parameters are way to useful in scripts to switch off, and the fact that you could simply write "Author:" because the comment is never ever intended for machine consumption (which would merit the ugly "@author" label) suggest that it would be better to fix the script than to add ugly hacks to "fix" this issue.

Do you strongly disagree? If so, please feel free to work on the fix and I will gladly review the pull request.
Comment 2 Mark Hiner 2014-08-29 10:55:55 CDT
See also: http://imagej.net/Script_parameters

Put any non @-prefixed line before your @author javadoc and the script should work, as well.

The problem with trying to detect and avoid something like javadoc is that the scripting framework allows aliasing of any class to a single keyword. So "@author" could actually be a valid class alias.

We could at least reduce the chance for such misunderstandings by terminating parameter parsing if we encounter a class with no alias.

see: https://github.com/scijava/scijava-common/issues/117

The relevant code is:
https://github.com/scijava/scijava-common/blob/master/src/main/java/org/scijava/script/ScriptInfo.java#L208-244
Comment 3 Curtis Rueden 2014-08-29 12:12:23 CDT
Another possibility would be to tweak the parameter annotation mechanism to have a leading line, and a trailing line, marking the start and end of the annotations, respectively. Something like:

// @@@
// @String name
// @OUTPUT String greeting
// @@@

That would reduce the chance of comments being misinterpreted.

Another possible solution would be to only respect the "until end of line" style comments for parameters. So:

// @author name

Would be a parameter, but:

/*
 * @author name
 */

Would not, because it does not start with "//"

Mark and I discussed adding a "getCommentString" to the ScriptLanguage interface which would facilitate this sort of parsing.

Stephan, any other suggestions to improve this?
Comment 4 Stephan Saalfeld 2014-09-02 15:23:31 CDT
Thanks for the comments.  Please feel free to mark as WONTFIX or proceed at your best liking.  I have reported this because I thought it may be an oversight and as such worth fixing, not aware that adding am non-@ comment before would work around it.  No further thought involved.  I like Javadoc/ Doxygen style comments to help my mental parser but if I can still use them by adding a meaningful comment first, I am happy.
Comment 5 Curtis Rueden 2014-09-03 14:31:28 CDT
OK, we won't worry about it for now. Thanks for the feedback, Stephan!