Unify Scijava and Beaker languages ?

[hadim]

I really don't know if it's a good idea. I only open this issue for discussion and to know what your guys think about that.

From the ImageJ side, we have some very specific needs the way we interpret the source code (I am thinking about the @Annotations for example). Saying that some code could probably be shared between both projects.

Scijava scripting languages are now used for years and are pretty stable. By having a JSR-223-compliant base kernel, I think it would be pretty easy for Beaker to use those packages.

What do you think @ctrueden ?

[scottdraves]

This sounds interesting I have to learn more about scijava and jsr223 and @annotations. Thanks for bringing it to our attention. Not sure what you mean about your needs, if you could elaborate I would appreciate it.

[hadim]

@annotation are an ImageJ specific feature that allow script devs to add custom input and output parameters.

Input parameters can then be specified by the user during execution according to context. For example in a "GUI" context, ImageJ will pop up a window with custom fields corresponding to those parameters.

You can learn more about it here https://imagej.net/Script_Parameters

[hadim]

And Scijava is the underlying Java framework that power all the ImageJ ecosystem : https://imagej.net/SciJava

[ctrueden]

Firstly, I want to emphasize that SciJava is a foundational layer unspecific to images. We have been building up this foundational layer for years, such that ImageJ is now the flagship—but not the sole—use case on top of it. That said, all of this software is still early/flexible enough that it could be restructured (e.g.: to cut SciJava Common into pieces) as needed in response to any requirements discussions here.

Crash course on SciJava Common

To learn about the relevant aspects of the SciJava Common library, this presentation may be the fastest way forward. But for the lazy :wink:, here is a quick primer. Suppose we have the following SciJava Groovy script:

// @String name
// @int age
// @OUTPUT String greeting
greeting = "Hello " + name + ". You are " + age + " years old."

When this script is executed by the SciJava Script Editor, a preprocessing chain occurs which tries to populate the needed inputs. If the SciJava Swing UI components are on the classpath, then a Swing dialog box will be shown as part of that input harvesting processing, which looks like this:

Afterward, outputs are handled by postprocessors. The DisplayPostprocessor plugin handles actual visualization of the outputs, which in the case above ends up showing this scrappy-looking window:

The ImageJ Common and ImageJ UI Swing components add support for images as inputs and outputs.

These chains are totally customizable, based on available SciJava plugins. For example, the KNIME image processing extensions use SciJava, but handle the pre- and postprocessing quite differently than ImageJ does.

Full details about these systems can be found in the ImageJ2 technical paper.

Goal/requirement r.e. scientific notebooks

What @hadim and I want to achieve within a scientific notebook is the ability to write "SciJava-style" script snippets, which render as beautifully/functionally as possible in the notebook, using parameters specified simply as above. We thought creating a scijava-jupyter-kernel would be a great way forward here. We could render the SciJava module input parameters as widgets in the notebook, and render the outputs as, well, output.

I admit that I have not had time to look at BeakerX in any level of detail, so I don't feel properly equipped to intelligently and deeply discuss @hadim's idea here. However, naively and from my biased perspective, the SciJava script annotations seem potentially general enough to be useful here, far beyond only ImageJ/life-sciences.

It would certainly be unfortunate if BeakerX, or Jupyter JVM kernel(s) in general, ended up needlessly inventing something equivalent to this mechanism. And it would be totally excellent if we could hack together commonly useful components along these lines. I will do my best to be responsive to discussion, requirements planning, etc., here, if this is a direction which looks interesting or viable for the BeakerX team. I am also available to video chat, if that would be helpful to move things forward.