Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 366322

Summary:	Chain Completion based on JDT
Product:	z_Archived	Reporter:	Marcel Bruch <marcel.bruch>
Component:	Recommenders	Assignee:	Marcel Bruch <marcel.bruch>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	lerch, sebastian
Version:	unspecified	Keywords:	plan
Target Milestone:	---
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:	completion, committed

Description Marcel Bruch

2011-12-11 02:51:33 EST

For Juno Release, Code Recommenders will deliver a pure jdt-based call chain completion as described here: http://code-recommenders.blogspot.com/2010/12/how-do-i-get-instance-of.html

A preliminary version has been delivered by Gary Fritz, Andreas Kaluza, and Marko Martin. We are refining the implementation for Juno now.

Comment 1 Sebastian Proksch

2011-12-14 09:29:25 EST

feedback based on the code review:

* limit call chain depth in the graph that is built
* preferences for: maximum depth, timeout for searching and number of proposed entries
* static methods of super types should be included as entry points
* generated templates need to include the variable types
* completion should overwrite highlighted text when invoked on a selection

Comment 2 Marcel Bruch

2011-12-21 01:44:31 EST

Status update:

Done:
> * limit call chain depth in the graph that is built
> * static methods of super types should be included as entry points

Todo:
> * preferences for: maximum depth, timeout for searching and number of proposed
> entries
> * generated templates need to include the variable types
> * completion should overwrite highlighted text when invoked on a selection

Comment 3 Marcel Bruch

2012-01-15 06:38:10 EST

I added several exclusion filters, e.g., to java.lang.String and java.lang.Object to improve performance (better don't try to resolve any call chains for these types). 

I also added a toString-filter that simply cuts off graph traversal for toString() methods.

Furthermore, I limited the number of proposals to ~20. I think it doesn't make sense to offer more than a this number of proposals. We should consider other filtering criteria that leverage usage data instead.

Having said all this, I propose to skip the preference page for now.

The proposal completion issues (namely parameter completion) are hard to address. This requires deep research on the Eclipse JDT APIs. I`ll close this bug and open another plan item for supporting parameter guessing.