Complex Completion Proposal

[kovadam69]

Based on venkato's proposal I did the changes on the current master branch. I did also some enhancement to give more precise completions and support more cases (like resolving complex completions in function call, etc.). I updated the ExampleCode java test case for the demo application to reflect the changes.

[kovadam69]

I did some further enhancements which include:
a.) better parameter completion suggestions based on parameter type compared to variable / method return types, including superclasses and interfaces. eg if the method accepts a Serializable class (like public void doSomestuff(Serializable s) , then all fields, which type implement Serializable and all methods, which return value implements Serializable will be listed. (this also guilt for local defined inner classes, etc)
b.) better code completion for classes and types in the current Compliation Unit
c.) better code completion for generic types like List, Map, etc, the types are now determined properly, even in this case:
class MyList < T extends java.awt.Component > extends ArrayList< T > {}

MyList < JTextField > x = new MyList < > ();

x.get => in completion you will get type JTextField as return type for method get
x.get(0). => you will get completion for JTextField type (eg. getText exists in the list, where getText does not exists in Component)

d.) fixed interface parsing, where interface did not contain any declaration (empty interface) eg.
public interface x {} . Current code does not set the Body end offset, and it remains null.

I will do some further testing before committing these changes, but looks good.

[kovadam69]

Did some further testing and bug fixing.
Also managed to process for cycle variables, variables in for cycle are added now as local variables, completion and Ctrl-Click works. for (int x,y = 0;...) and for (Iterator it=.;it.hasNext();) and for (Object o : list) are supported.
Did some enhancements regarding memory leaks, used WeakReference in some cases, where reference to a class holding reference to JarManager was hold. Also modified the LanguageSupportFactory to use WeakHashMap to cache LanguageSupport objects, this way if necessary, unused LanguageSupport classes can be GC'd. (JarManager can take up lot of memory).
Some modification also affected AutoComplete project, I will push a pull request there separately.
I do some more testing next week, and then I will commit current changes when they are stable enough.

[kovadam69]

I uploaded now the files. I still test and fix if find anything, but now it has a lot of new features, and is almost more usable as the Netbeans code editor :) Later I will write here a review of all features currently supported. Important notice: there are changes in the AutoComplete library, which are needed for this library as well!

[kovadam69]

So the feature list of current code stand:

• multi-level completion proposals, like: map.get("x").toString().equals()
• "this" support for current class (like this.value = value)
• "this" support for enclosing types from non-static inner classes: ExampleCode.this.
• enhanced type parameter handling, most cases the type parameters are recognized correctly (like list.get(), map.get(), etc. will use correct return values)
• for cycle variable is accessible in for cycle code block as local variable for proposals (for (Object o : list) { o.toString(); } completions for o will work
• enhanced search using IntelliJ like search mechanism (AccUt search text will match AccountingUtils and AccessUtils), this is also applied to method parameter completions (see pull request for AutoComplete library)
• completions in method calls find correctly method call boundaries and loads proper proposals (like list.add(ExampleCode.this.getX()))
• "super" support in method bodies, like super.toString()
• "super" constructor call support in constructors with parameters
• enhanced proposal after "new" keyword: variable definition, return statement and method parameter ("var = new " => var identifier is extracted, type gathered, constructors for var type (and compatible subclasses) are shown only (eg: List var = new , proposal will show 3 ArrayList constructors, if arraylist is imported!) /
  "return new " => method identified, method return type extracted, constructors for return type (and compatible subclasses) are shown only / "public String getString() { return new " => will show proposals for lot of String constructor (String is final, no subclass here))
  "list.add(new " or "list.add(0, new " will extract variable type, search for method with similar signature (only parameter count is checked, not type), and creates constructor proposal for possible classes (if multiple methods found with "same" signature, multiple types are used to create the proposal)
• newly created objects can be used in completion, like: new ArrayList(). will work and add proposals for ArrayList methods
• enhanced Ctrl-Click support (local vars, methods, fields, class names, for cycle variables and method parameters in current CompilationUnit, and external class/method/field jump with listener)

[kovadam69]

Last two enhancement added which was in my mind (further optimization (eg adding method parameter type check, etc) would require a much bigger refactoring):

• ctrl-space in a method call will try to get the method parameter index and tries to load completions for given method parameter type (at current index) (if multiple methods has similar signature (from method parameter count view) it will offer completion for multiple types)
• variable assignment will also try to load proper local vars, methods, fields (eg. "List x = " will load local variables, methods, fields, which type/return type is compatible with List)

Now the big question is, when can you review the changes and merge with master branch? Since these modifications make the usability of Java code completion much-much better. I assume it is at least at Netbeans editor level, or even a bit more in some cases (of course some cases also worse).
Thanks!

[kovadam69]

One last thing I was missing is working now too: if you are in a method call, pressing Ctrl-P will pop up the tooltip about the method's parameters. If it finds multiple methods with similar signature, it will show multiple popups for each match. This should also work for constructor and super constructor parameters as well. This required some modification in the AutoComplete library. I pushed there the changes separately. It isn't anything which would destroy any other completion, most provider return null or just use the default implementation when calling the getParameterizedCompletions method of CompletionProvider interface. In JavaCompletionProvider this method call returned NULL previously, now I forward this call to the SourceCompletionProvider, which gathers the possible method parameters, and returns it. This way now a nice tooltip is shown with the possible method parameters. Big help when coding. :)

[kovadam69]

The last bunch of changes add better support for subclasses (like MyClass.MyInnerClass x = new MyClass.MyInnerClass(); x. => will give proposal for MyInnerClass methods)

[venkato]

Wow! Works. It very nice!