Fifesoft Blog

If you’re using the JavaLanguageSupport in the RSTALanguageSupport trunk, I’d appreciate it if you checked out the latest and tried it out.  It has a nice new feature in that, if source is attached to jars on the classpath, code completion suggestions for methods will include the methods’ parameter names (assuming they can be found in Javadoc for the method):

Method param names in choices window

Method param names in parameter assistance

Previously, parameter names were grepped out of the source file being edited’s methods, but for any compiled classes on the “classpath,” method parameters were identified by their type only.  The only way to know what each parameter was (short of having the API you’re using memorized) was to read the information in the description window.

Now, Java support has taken the next step.  It’s already reading the Javadoc for each method to put it into the description window, so why not grep the parameter names out of it, and use them everywhere else, such as the main code completion choices window?

If you point your application to a JDK, it’ll automatically locate the source zip (actually, it already did this). and this feature will work out-of-the-box!

My only concern is performance.  This is an un-optimized feature, and it does result in significantly more I/O (reading from the source zip or directory) than was done previously.  Memory consumption should be about the same, though there may be a lot more smaller temporary objects created (i.e. more GC).  So I request that if you grab the latest, you report back to me if there are any performance issues.

Have fun!

The fun never stops!  A couple more enhancements have been added to JavaLanguageSupport in the past few days.  Both of these are actually possible thanks to enhancements to the AutoComplete library, so you’ll need to update that too, but currently the Java code completion is the only thing that takes advantage of them.

First off, Java completion choices are now sorted by relevance, instead of alphabetically:

Sort by Relevance

Note how the local variables and members are displayed before methods, which are both displayed before class names.  Previously everything was sorted purely alphabetically, putting the things you’re most likely to type (variables, fields and methods) in the middle of a huge amount of classes you’re less likely to want.

The next enhancement is completion suggestions for method parameters.  Now, not only do you get the nifty Eclipse-like parameter tool tip, parameter highlighting, and tab-to-move-between-params, you’ll also get a small popup listing all local variables, members, and getters whose types match (or are subtypes of) the type required for the currently-focused parameter!

Parameter choices completion

Although in the example above there are only a small number of suggestions, note that again, the completions are sorted by relevance.  Also note that you’ll get “null” as a standard suggestion for non-primitive types, and “0″ as a standard suggestion for numeric primitive types.

There have been some great improvements to the Java language support in RSTALanguageSupport.  If you haven’t looked at it lately, here’s what you’re missing out on:

1. Import statements are added when code completion inserts a class name that has not yet been imported.  Following in the footsteps of IDE’s such as Eclipse, this feature prevents you from having to manually enter all your import statements; just type away, and hit Ctrl+Space to have them added for you.  Thanks go out to users Guilherme and Jonatas for the initial implementation of this feature, and for making me get off my bum and start working again on the library!

Before...

... and after.

2. Duplicate local variable names are squiggle-underlined and flagged as errors.  A small but useful check.

Duplicate local variables - syntax error

3. Fixed a bug, and now the code completion list correctly handles and shows multiple classes/interfaces with the same name, such as javax.swing.text.Document and org.w3c.dom.Document.  Previously only one such class would “win out” and be listed as a completion choice.  Now, they all have equal and fair representation!  Once again, the hard work was done by Guilherme and Jonatas.

Multiple classes/interfaces/enums with the same name

If you haven’t done so yet, download the RSTALanguageSupport project from SVN and give it a try!