Input harvesting throws exception

[imagejan]

When using a scijava-common-2.64.1-SNAPSHOT.jar from the current master (b431d27) in an (otherwise) up-to-date Fiji installation, the script input harvesting is broken.

Trying to run a simple script such as:

#@ String text
println text

gives an error: A String is required but none exist.
and throws the following exception:

[ERROR] Failed to refresh widget: class org.scijava.ui.awt.widget.AWTTextWidget on EDT
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1319)
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1294)
	at org.scijava.thread.DefaultThreadService.invoke(DefaultThreadService.java:117)
	at org.scijava.ui.AbstractUIInputWidget.refreshWidget(AbstractUIInputWidget.java:82)
	at org.scijava.ui.awt.widget.AWTTextWidget.set(AWTTextWidget.java:75)
	at org.scijava.ui.awt.widget.AWTTextWidget.set(AWTTextWidget.java:50)
	at org.scijava.plugin.WrapperService.create(WrapperService.java:67)
	at org.scijava.widget.AbstractInputHarvester.addInput(AbstractInputHarvester.java:110)
	at org.scijava.widget.AbstractInputHarvester.buildPanel(AbstractInputHarvester.java:84)
	at org.scijava.widget.InputHarvester.harvest(InputHarvester.java:69)
	at org.scijava.ui.AbstractInputHarvesterPlugin.process(AbstractInputHarvesterPlugin.java:76)
	at org.scijava.module.ModuleRunner.preProcess(ModuleRunner.java:104)
	at org.scijava.module.ModuleRunner.run(ModuleRunner.java:156)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:126)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:65)
	at org.scijava.thread.DefaultThreadService$3.call(DefaultThreadService.java:237)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
	at org.scijava.ui.awt.widget.AWTTextWidget.doRefresh(AWTTextWidget.java:97)
	at org.scijava.ui.AbstractUIInputWidget$1.run(AbstractUIInputWidget.java:85)
	at org.scijava.thread.DefaultThreadService$2.run(DefaultThreadService.java:220)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

(tested on both Windows and Mac OSX)

[ctrueden]

org.scijava.ui.awt.widget.AWTTextWidget

It shouldn't be using the scijava-ui-awt widget, but rather the scijava-ui-swing one. This looks like the same issue you ran into at scijava/scijava-ui-swing#27 (comment). Are you sure it happens with a clean Fiji with only the new scijava-common installed?

Even if not, it might nonetheless be a bug in the framework, if e.g. widgets are being instantiated to interrogate whether they are applicable, and then discarded, but when interrogating AWTTextWidget it throws an exception... in which case, the bug is probably not here in SJC but rather in scijava-ui-awt.

[ctrueden]

I've run into another suspiciously similar problem when pinning to the latest scijava-common SNAPSHOT in a project I am working on. The stack trace is:

[ERROR] Module threw error
java.lang.StackOverflowError
	at org.scijava.widget.AbstractInputWidget.supports(AbstractInputWidget.java:1)
	at org.scijava.ui.awt.widget.AWTMessageWidget.supports(AWTMessageWidget.java:86)
	at org.scijava.ui.awt.widget.AWTMessageWidget.supports(AWTMessageWidget.java:48)
	at org.scijava.widget.AbstractInputWidget.supports(AbstractInputWidget.java:1)
	at org.scijava.ui.awt.widget.AWTMessageWidget.supports(AWTMessageWidget.java:86)
	at org.scijava.ui.awt.widget.AWTMessageWidget.supports(AWTMessageWidget.java:48)
	at org.scijava.widget.AbstractInputWidget.supports(AbstractInputWidget.java:1)
	...

Will investigate tonight and/or tomorrow.

[ctrueden]

Reverting 596813c fixes the problem I'm encountering.

@imagejan It would be good if you could test whether reverting that commit also fixes the error you are seeing on your system(s). Even though that commit merged to master recently, it has been a long time since I actually authored it, so I'll need to dig in a bit to understand again why I thought it was necessary. Then decide how to proceed from there.

[ctrueden]

As described in the reverted commit, the DataHandle logic needs that commit to match locations to data handles properly. Without it, the DownloadServiceTest (on the download branch) complains thusly:

java.lang.ClassCastException: org.scijava.io.location.FileLocation cannot be cast to org.scijava.io.location.BytesLocation
	at org.scijava.io.handle.BytesHandle.bytes(BytesHandle.java:166)
	at org.scijava.io.handle.BytesHandle.length(BytesHandle.java:77)
	at org.scijava.download.DefaultDownloadService.copy(DefaultDownloadService.java:129)
	at org.scijava.download.DefaultDownloadService.lambda$0(DefaultDownloadService.java:72)

Too thorny for tonight; I'll dig tomorrow morning.

[imagejan]

@ctrueden wrote:

It would be good if you could test whether reverting that commit also fixes the error you are seeing on your system(s).

Interestingly, reverting the commit now leads to a StackOverflowError for me:

[ERROR] Module threw error
java.lang.StackOverflowError
	at org.scijava.widget.InputWidget.supports(InputWidget.java:58)
	at org.scijava.ui.swing.widget.SwingMessageWidget.supports(SwingMessageWidget.java:88)
	at org.scijava.widget.InputWidget.supports(InputWidget.java:58)
	at org.scijava.ui.swing.widget.SwingMessageWidget.supports(SwingMessageWidget.java:88)
	at org.scijava.widget.InputWidget.supports(InputWidget.java:58)
	at org.scijava.ui.swing.widget.SwingMessageWidget.supports(SwingMessageWidget.java:88)
	at org.scijava.widget.InputWidget.supports(InputWidget.java:58)
	at org.scijava.ui.swing.widget.SwingMessageWidget.supports(SwingMessageWidget.java:88)
	at org.scijava.widget.InputWidget.supports(InputWidget.java:58)

I'll try to dig deeper as well with a fresh Fiji without additional update sites etc.

[imagejan]

Ok, it seems I had some undefined state caused by not running mvn clean before rebuilding. Now I tried in a fresh Fiji, and reverting the commit indeed fixes the input harvesting issue.