More helpful Java code completion – Feedback please!

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 choices window

Method param names in parameter assistance

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!

5 Responses to “More helpful Java code completion – Feedback please!”

  1. Bob Fisch says:


    I’ve just put the new source into Unimozer and will do some tests later on…

    Actually I wonder how I could tell the application to use the official JDK JavaDoc ( I’ve tried to use a “JarInfo” pointing to the ZIP, but this didn’t work out.

    I’m running MAC OSX, having the JDK installed by the OS but not the JavaDoc…

  2. admin says:

    Hi Bob,

    You currently cannot point to a Javadoc zip file, you have to point to a source zip (or a directory of .java files). And being on OS X, I believe (could be mistaken though) the source in “src.jar” instead of “” inside of a JDK. I know I’ve tested this on OS X. On my particular machine, the Java 6 JDK did not include a src.jar, whereas the JDK5 did. Not sure if that’s because JDK5 is the “official” JDK version on OS X 10.5, or what. Nevertheless, it was able to successfully grab and use doc comments from src.jar when I pointed it to the Java 5 SDK.

    But if you’re having trouble pointing to a source zip/jar file, can you provide a code snippet of how you’re trying to do it?

  3. Bob Fisch says:


    I’ve done this:

    JarInfo javaSrcInfo = new JarInfo(new File(“/Users/robertfisch/Desktop/src”));
    javaSrcInfo.setSourceLocation(new File(“/Users/robertfisch/Desktop/src”));
    ((JavaLanguageSupport) ls).getJarManager().addJar(javaSrcInfo);

    I’ve also tried to use directely the ZIP file, but that didn’t worked out either 🙁



  4. admin says:

    The following works for me, when I add it into, and ran the demo on OS X:

    try {
    JarInfo ji = new JarInfo(new File(“./bin”));
    ji.setSourceLocation(new File(“./src”));
    } catch (IOException ioe) {

    This adds both code completion for the standard JDK classes, as well as for classes in the RSTALanguageSupport project, both with Javadoc support (from the source). To launch the demo, I pointed to the 1.5.0 system JDK, which lives in this location:


    The library auto-detected the src.jar that lives in this directory, as it knows to scan for “src.jar” in the relative path OS X puts it in.

    Do you have this JDK installed? Or perhaps a different one that contains src.jar? I noticed that my 1.6.x JDK does not contain src.jar, but my 1.4 and 1.5 both do.

    Can you try modifying the file as I did, to see if it works? This will test both source in a jar/zip, as well as in a directory.

  5. Bob Fisch says:


    Placing the “src.jar” (renamed from “”) into the right directory does the trick for Mac OSX.

    Under Windows, I now have the problem, that when a JRE and a JDK is installed, Windows defaults to use the JRE. So I had to tweak somewhat arround to find the right directory which contains the “”.

    Anyway, I’ve got it now up and running. Thanks for your help …