Question 1: where is the actual languageSupportService declared?
Question 2: how does one find out what properties the languageSupportService has?
Question 3: how does one register an additional service for e.g. jython, so that the language suport service engine can find it?
Question 4: how and where does one package it?
Iâve pointed out in the past that this style of programming is opaque to developers other than who authored the code, because it is not discoverable via IDEs, and it is not discoverable, or not easily, at run time via reflection or code introspection.
At scijava/scripting-jython, the jython language is defined rather simply, and it points to the AdaptedScriptLanguage:
⊠using a rather simple constructor call:
public JythonScriptLanguage() {
super("jython");
}
And Iâve found the AdaptedScriptLanguage (the superclass) after some guessing here in scijiava/scijava-common:
⊠with the constructor then calling findFactory("jython"). That then relies on a ScriptEngineManager, so the can has been kicked further down the abstraction road. Now where is that. Definitely not here, surprisingly:
The fragmentation of scijava into a myriad of tiny repositories makes it nearly impossible to navigate, except, I guess, if one git checkout all scijava repositories into oneâs workspace folder in e.g. eclipse. Or is there another way?
So the ScriptEngineManager is not in scijava-common. Bummer. And the obviously named scijava-scripts is not about scripting in scijava, but rather, bash scripts than run in the command line. If not that, then which of these scijava repositories?
By the look of it, none of them.
Of course, I didnât realize that the ScriptEngineManager is javax.script.ScriptEngineManager. So Iâve reached a dead end, because that is just a JVM built-in. Still no hint as to where the jython ScriptEngine may be.
I want to extend the jython ScriptEngine. It really shouldnât be this hard to find.
⊠and it turns out that, perhaps, itâs provided by jython-slim-2.7.2.jar itself. Seems the most plausible.
So to update scijavaâs ScriptEngine for jython, I have to do so ⊠in the jython repository itself. Perhaps that makes sense, but this means I canât provide additional features to that engine without commiting code to the upstream jython project. Thatâs too much to ask, given that the code I want to add is Fiji-specific.
Iâm going to take this finding as a license to implement an ad-hoc solution for jython in the Script Editor.
Turns out, there may still be a way to provide custom autocompletion code for jython in the Script Editor: the RSyntaxArea language support accepts plugins (for documentation: the RSyntaxArea is an extended JEditorPane that does syntax highlighting and much more, and where text is written in the Script Editor). There are two such plugins in there, implemented for java and for javascript, in the Script Editor repository:
Letâs see how far I can go that way. Well, not too far: Iâve created a class for JythonLanguageSupportPlugin within the script editor repository, which looks like:
@Plugin(type = LanguageSupportPlugin.class)
public class JythonLanguageSupportPlugin extends AbstractLanguageSupport implements LanguageSupportPlugin
{
private JythonAutoCompletionProxy acp;
private RSyntaxTextArea text_area;
public JythonLanguageSupportPlugin() {
setAutoCompleteEnabled(true);
setShowDescWindow(true);
}
@Override
public String getLanguageName() {
return "jython";
}
@Override
public void install(final RSyntaxTextArea textArea) {
this.text_area = textArea;
this.acp = new JythonAutoCompletionProxy(new JythonAutocompletionProvider(text_area, new JythonImportFormat()));
}
@Override
public void uninstall(final RSyntaxTextArea textArea) {
if (textArea == this.text_area)
this.acp.uninstall();
}
}
⊠so, in the EditorPane.setLanguage, Iâd expect the support to not be null for âjythonâ. but it is.
Question: what else, beyond the @PlugIn parameter of the class, is needed for this to work?
After all these unnecessary hours, the LanguageSupportService has bent to my long search across undocumented features, undiscoverable injected magic and disparate repositories. So now there is autocompletion support for python (jython) in the Fiji Script Editor. Limited, though, to importing java classesâitâs a start. And it can, and hopefully will, get much better.
Have you read the âSciJava in Detailâ notebook?
I acknowledge your opinion. But the entire design of SciJava and ImageJ2 is built around type-safe extensibility via plugins. Changing this design would eliminate ImageJâs primary advantage.
In general: In Eclipse, ctrl+T lists the available implementations of an interface. Which one is used will depend on the runtime environment.
The properties (methods, really) are those defined in the interface. You should not rely on any properties defined in specific implementation, as they are intended to be internal only.
The LanguageSupportService is the service that manages available LanguageSupportPlugins. You should not need to implement your own LanguageSupportService (although the SciJava design allows it, if you need to override the infrastructure of how LanguageSupportPlugins are managed). Rather, if you are looking to support a new language in the script editor, youâd make a class implementing LanguageSupportPlugin and annotated with @Plugin(type = LanguageSupportPlugin.class).
Here is an example for JavaScript. Note that it is just a thin extension of the RSyntaxTextArea projectâs JavaScriptLanguageSupport class.
Assuming you imported a project of interest into Eclipse via the Maven support (File âș Import âș Existing Maven Project), Eclipse should allow you to browse into the source code of classes residing within dependencies, via downloaded-on-demand -sources JARs. Just use the usual F3 mechanism or whatnot. This works especially well if you import a toplevel project such as Fiji itself.
That ScriptEngine implementation is part of Jython itself:
Here is how I found it using Eclipse:
Import Fiji via File âș Import âș Existing Maven Project:
Iâm not sure how helpful it will be to dig into the Jython ScriptEngine implementation, though. Earlier you mentioned LanguageSupportPlugin⊠that is not the script engine, but rather for RSyntaxTextAreaâs language support.
What are you trying to achieve? I missed your last couple of messages aboveâI understand now what you were trying to do. Congratulations on getting it working.
Yes, the entire advantage of scijava over ImageJ1 disappears. What was lost, though, is the ability of the non-expert to contribute, given the nearly insurmountable amount of a priori knowledge on tooling necessary to waddle through the interface forests and runtime service discovery systems.
Indeed, I got somewhere, so it wasnât all wasted. And indeed I use F3 lots in eclipse, but interfaces have a way of getting one nowhere. Didnât occur to me to use the type hierarchy (via control + T or else), as I was under the impression that the classes wouldnât be found since they werenât in my imported projects. Will try to remember this going forward, thanks for making me realize that mvn does a lot more than I give it credit for.
Now I have to finish the Jython autocompletion system, yet most of my hours were committed to even finding out where to add the code that I already had working. This too shall pass, until I forget it all and have to discover it again. At least now there is this detailed tutorial. Whoever implements the next autocompletion system for the Fiji Script Editor, I hope all the above works as the necessary introduction.
On the tutorial on scijava, as a general explanation of whatâs going on it is informative. To develop plugins on top of the ImageJ2 software stack, it reads like it should help (but I havenât, and probably wonât). To develop the stack itself, it falls very short.
From my perspective, SCIFIO continues to endure growing pains in the form of performance issues (I understand the ImageJ2 project is understaffed). Image Ops are a complication layer, only simplifying code for those that already know how it all works underneath; reminds me of the Dylan programming language, which was at its most useful if one already knew lisp and understood the transformations that it made to simplify some obtuse lisp constructs. And scijava I find often impenetrable, a fragmentation of what once was a monolithic project (fiji) into a myriad of libraries that facilitate independent development at the cost of preventing outside developers from contributing unless they internalize the overall structure as if it still was the monolithic architecture that it used to be. Perhaps it suffers from second-system symptoms, but the good part is that it works and services thousands around the world. Itâs just so hard to do anything with it as an outsider.
In summary, I am happy it all works, and thankful that you maintain it. Letâs hope some day it will actually be the easy entry-level hacking platform that would attract those entering the project from tangential disciplines through sheer need to get an as yet non-existing feature built.
what often helps me in the SciJava jungle is the debugger of the IDE. Write a little main function that opens a script editor and set a break point for example here. You can then inspect what script languages exist during runtime. And if you know the package and classname of a specific language, you can search for it in Fijis search bar to figure out its jar filename. Hopefully you can make a good guess from the jar name to the github repository name.
Btw. I was also not happy that maven, compilation of Fiji plugins and writing them is a lot more complicated than compiling a Java plugin with ImageJ1. Thatâs why I made a Fiji plugin code generator for clij. As you are my target audience for this, I would love to hear your feedback. Any hint that makes it even easier for people to contribute new plugins is very welcome
Thatâs cool @haesleinhuepf! A modern version of Kai Uwe Barthelâs visual programming framework for ImageJ.
On breakpoints: thanks, indeed, I should use the eclipse debugger more often. But the point stands about lack of discoverabilityâif it needs introspection inside a debugger, an API isnât developer-friendly.
Note if you have seen the end of the video: From the visual graph you can generate maven-based Java code and compile it to Fiji plugins from within Fiji
