Request for feedback: class search

I have coded a Searcher plugin for the SciJava search framework that looks for loaded classes in the current JVM. I am looking for feedback from developers and power users on whether this is useful, as well as how best to handle a related privacy issue.

Here is what the class search currently looks like:

If you want to try it out, clone the scijava/scijava-search repository, check out the class-search branch, and build it using mvn. Then copy the target/scijava-search-0.6.0-SNAPSHOT.jar into jars/ of an ImageJ2/Fiji installation, deleting the existing jars/scijava-search-0.5.0.jar artifact. You should then have a new “Classes” section in the search results.

My questions are:

  1. Is this useful?
  2. Can you think of any other actions besides Javadoc and Source you’d like to see?
  3. Any other information you’d like to see reported in the details pane?

And finally: the privacy question. To make the Javadoc button work, I introduced a JavadocService that talks to to compile the list of known packages across the SciJava ecosystem. This is very nice because any class with a package available from that portal will have a Javadoc button that launches the portal at the correct location. However, for performance reasons, the service currently talks to the remote URLs during initialization using several threads, so that the javadoc is ready to go within a few seconds. Without this optimization, we’d have to do something like: blindly show the Javadoc button before we really know if javadoc is available, compiling the javadoc packages upon first click of a javadoc button, which is likely to create a several-seconds-or-longer delay before the first javadoc request can be completed. So the question is: how should this best be handled?


I think so. I am not using Fiji a lot but I can imagine that this is super useful for scripting inside Fiji. This is probably also helpful for debugging and checking if a desired class is loaded.

This is probably (way) beyond the scope of this topic but I could see something like displaying the requested class JavaDoc inside a floating Fiji window instead of a browser, and then have the window update on request with the class/method at the current cursor in a scripting/editor window.

FYI, just toying around with this, I noticed that it prodocues a broken link for RandomAccessibleInterval doc. I used a Fiji zip that I downloaded in October, if that matters.

This could be configurable, i.e. by default it does not talk to any remote URLs, unless the user specifies so (there could be an appropriate hint). Also, in the could the JavaDoc button be added dynamically for all current search matches, with an additional notification that the JavaDoc build is in progress (and there might be no JavaDoc for that class)?


Thanks for the feedback, @hanslovsky.

I decided to make the JavadocService lazily initialized, like most other SciJava services. When the user clicks the Javadoc button for the first time, the URLs get queried. The status bar displays progress indicating what is happening.

Updated branch is now merged to master:

This is because net.imglib2 is a package present in at least one component of Fiji (see the package list of ), and the Fiji project is parsed before the ImgLib2 project. Perhaps the code should parse the entire class list, rather than only the package list.



So e.g. RandomAccessibleInterval javadoc opens correctly now.

And scijava-search version 0.6.0 is released. Coming soon to a Fiji near you.