NOTICE! This is a static HTML version of a legacy Fiji BugZilla bug.

The Fiji project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Bug 817 - 'Add import...' in the script editor does not add package info
'Add import...' in the script editor does not add package info
Status: FIXPENDING
Product: Fiji
Classification: Unclassified
Component: Plugins
unspecified
Macintosh Mac OS
: P4 normal
Assigned To: ImageJ Bugs Mailing List
Depends on:
Blocks:
 
Reported: 2014-06-25 08:58 CDT by Jan Eglinger
Modified: 2016-01-13 15:21 CST
4 users (show)

See Also:

Description Jan Eglinger 2014-06-25 08:58:43 CDT
- Open the script editor ('File > New > Script...')
- change the language to Java ('Language > Java')
- type any class name in the text window (e.g. 'IJ', 'GenericDialog', 'wtf')
- select the word you just typed
- 'Edit > Add import...'

The script editor will just add a line with the selected text (e.g.
  import IJ;
  import GenericDialog;
  import wtf;
) without checking the existence of the class name in any known package.

In previous versions, 'Add import...' used to add the fully qualified class paths, e.g.
  import ij.IJ;
  import ij.gui.GenericDialog;

Information about your version of Java:

  os.arch => x86_64
  os.name => Mac OS X
  os.version => 10.9.3
  java.version => 1.6.0_65
  java.vendor => Apple Inc.
  java.runtime.name => Java(TM) SE Runtime Environment
  java.runtime.version => 1.6.0_65-b14-462-11M4609
  java.vm.name => Java HotSpot(TM) 64-Bit Server VM
  java.vm.version => 20.65-b04-462
  java.vm.vendor => Apple Inc.
  java.vm.info => mixed mode
  java.awt.graphicsenv => apple.awt.CGraphicsEnvironment
  java.specification.name => Java Platform API Specification
  java.specification.version => 1.6
  sun.cpu.endian => little
  sun.desktop => null
  file.separator => /

The up-to-date check says: REMIND_LATER

Information relevant to JAVA_HOME related problems:

  JAVA_HOME is set to: null
  imagej.dir => /Users/eglinger/Fiji-debug/Fiji.app

Information about the version of each plugin:

Activated update sites:
ImageJ: http://update.imagej.net/ (last check:20140623222553)
Fiji: http://fiji.sc/update/ (last check:20140624002555)
Comment 1 Curtis Rueden 2014-06-29 22:14:19 CDT
It looks like the entire fiji.scripting.completion package did not make it into the ImageJ2 version of the Script Editor. Johannes, is the port merely unfinished, or is there some other reason for that? Licensing issues? Or can we migrate the code from that package to fix this issue?
Comment 2 Johannes Schindelin 2014-06-30 09:25:25 CDT
Yes, I confirm that the auto-completion "support" was completely scratched from the script editor. It never worked, and I decided at some stage that I cannot be held responsible for cleaning up a Google Summer of Code project for which I was neither student nor mentor (and for which I already did a lot, a really big lot more than was my due as administrator for the Fiji organization).

The auto-completion support was not really necessary for the "Add import" anyway. It's just that at some stage, the code to discover all available packages and classes needs to be reinstated. However, this requires a little care with regards to the separation of concern: Fiji's script editor was a pile of code that mixed GUI and function and Git support and a half-working auto-completion support and incomplete and inconsistent features that were available only for specific languages ("Edit>Add import", for example, is only available for Java! For no good reason, either). We can do much better than this! The auto-completion support, for example, is UI-agnostic. So it should not live in the same package as the script editor GUI. It is -- as the "Edit>Add import" command -- subject to language-specific code, so there needs to be a base interface in SciJava common (and either a new service or new API for the ScriptService), and the script languages need to implement said interfaces

Unfortunately, we still have a couple of issues to address before we can go to address power users' issues involving heavy script development. This issue is therefore not on my immediate radar, even if I assign it to myself.

In the meantime, everybody compelled to work on this is of course welcome to do so. Remember: Fiji is no longer a complaint-driven project, meaning that it is no longer enough to just complain and the work will be performed magically (it is actually not really magic when Mark, Curtis or I have do all the work...). Fiji is a collaboration-based project now.
Comment 3 Jan Eglinger 2014-06-30 11:01:33 CDT
Thanks, Johannes, for the clarification.
I never knew that the "Add import" feature was part of a planned auto-completion project. My bug report was not meant as a complaint, I just wanted to report the lost functionality as soon as I stumbled upon it, not knowing if it was intentional or just an oversight while migrating to the scijava framework. I understand that there are many more pressing issues.

While developers looking for auto-completion support will probably switch to a proper IDE anyways, I still think the "Add import..." feature was very useful for scripting users who might not have any knowledge of the detailed API structure, even might be even more useful if available for all scripting languages.

That said, I would be willing to contribute here if I find the time, but I would require some pointers how to proceed. Please excuse my absolute ignorance concerning the SciJava framework: for example, what needs to be done to migrate fiji.scripting.completion.ClassNames to SciJava?

Cheers,
Jan
Comment 4 Johannes Schindelin 2014-06-30 13:32:10 CDT
> That said, I would be willing to contribute here if I find the time, but I would require some pointers how to proceed.

Gladly!

For what it is worth, let me point out that I find the collaboration between you and me in particular very rewarding.

> for example, what needs to be done to migrate fiji.scripting.completion.ClassNames to SciJava?

Well, the first idea would be to identify the concerns. The first one is that you want to enumerate (i.e. provide an Iterable of some sort) a map of package names to class names contained in that package. The classes should be discovered on the class path -- which we can do easily, we even have code for that already: https://github.com/scijava/scijava-common/blob/54a8a5574b68309ea3f16b178e772b677867d666/src/main/java/org/scijava/annotations/EclipseHelper.java#L140-L157

Granted, this code is a little bit different from what we need: first of all, it does not decouple the enumeration of the classes from their processing (but this could be easily done through a callback interface, i.e. by passing an object implementing a certain interface whose single callback method is executed on all found classes).

The code in the EclipseHelper also has code to detect whether the passed URLClassLoader is unlikely to be called from within Eclipse (because the purpose of the EclipseHelper is to compensate for Eclipse's non-standards-compliant failure to process annotations while compiling, but we do not need that for the class importer).

I would suggest to adjust and move that code into the org.scijava.utils.ClassUtils class, as a static method accepting a ClassLoader and a ClassNameVisitor (which is how I would call the callback interface).

Then I would suggest to add two methods to the org.scijava.script.ScriptService interface: getClassMap(), returning a (cached) map of package names to class names, and getPackagesForClass(), returning a (cached) map of class names to package names. Of course, the org.scijava.script.DefaultScriptService needs default implementations of both.

The TextEditor can then make use of those new methods.
Comment 5 Mark Hiner 2016-01-13 15:21:20 CST
See https://github.com/imagej/imagej-ui-swing/pull/67 for my first pass at a simple implementation using the Reflections 3rd party library.