Repository navigation
Open
Description
The fact that DynamicCommand extends DefaultMutableModule but not CommandModule leads to CommandService.run() returning null, as explained in the [DEBUG] output here:
scijava-common/src/main/java/org/scijava/command/DefaultCommandService.java
Lines 345 to 363 in 80d0a38
| /** | |
| * A HACK to avoid {@link ClassCastException} when calling run when the | |
| * resultant module will not be a {@link CommandModule}. This is an API design | |
| * flaw in CommandService currently, but for now we work around it rather than | |
| * breaking backwards API compatibility. | |
| */ | |
| private Future<CommandModule> validateFuture(final Future<Module> future, | |
| final CommandInfo info) | |
| { | |
| try { | |
| final Class<?> commandClass = info.loadDelegateClass(); | |
| if (Module.class.isAssignableFrom(commandClass)) { | |
| log.debug("The command '" + info.getIdentifier() + | |
| "' extends Module directly. Due to a design flaw in the " + | |
| "CommandService API, the result cannot be coerced to a " + | |
| "Future<CommandModule>, so null will be returned instead. " + | |
| "If you need the resulting module, please instead call " + | |
| "moduleService.run(commandService.getCommand(commandClass), ...)."); | |
| return null; |
So the workaround is to get the CommandInfo and call ModuleService#run() on it to get the Future<Module>... but is there any chance to make it extend CommandModule but still implement the required interface MutableModule without breaking backwards compatibility?
Metadata
Metadata
Assignees
Labels
No labels
Activity