Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] Ask for suggestions on better implementation solutions 
Hi Cheng,


it's great to see you guys working on this fabulous engine to make it consumable by Eclipse users! To those that don't know what project we speak about, see http://stap.sjtu.edu.cn/~chengzhang/precise/ for an introduction to Precise - a smart parameter guessing completion engine for Eclipse. I'm following this project for a while now and I'm looking forward to see it in action!


Regarding your question:

First, two words about limitations when extending Eclipse JDT's completion engines. 
1. JDT takes it very serious when it comes to potentially hijacking of proposals of other engines. That means it's very simple to add new proposals but almost impossible to manipulate existing ones. 
2. You will almost always work with JDT's internal APIs and at some point in time you may also use reflection - there is noting bad about it for a proof of concept and if it turns out to be valuable we can ask JDT guys for opening their APIs. 

Having said this, I see two solutions to your problem. Given my limited knowledge of your code, I'm not sure they can be applied. Let me know if not. We can go for other solutions then.


Solution #1 (simplest - but probably too simple):
If you just want to *rearrange* existing proposals, you may have a look at the org.eclipse.jdt.ui.javaCompletionProposalSorters extension point. You can plug-in your own sorter that does all the scoring to show the proposal you deem more relevant on top. But if I've read your recent paper correctly, you also *add* new proposals.

Solution #2 (slightly more complex):
Create you own completion engine that jumps in on method argument completion only. Ayush opened JDT' JavaContentAssistContext for this kind of extensions in Eclipse 3.8 (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=340945)

In Eclipse JDT 3.8/4.2, you have methods InternalCompletionContext.getVisibleFields, InternalCompletionContext.getVisibleLocals, InternalCompletionContext.getVisibleMethods that return all potential candidates for parameter guessing. To make use of this API, you have to create you own extension of org.eclipse.jdt.ui.javaCompletionProposalComputer extension point and do some API traversal and type casting magic on the ContentAssistInvocationContext given in 

public List<ICompletionProposal> computeCompletionProposals(final ContentAssistInvocationContext javaContext,
            final IProgressMonitor monitor) 

To figure out whether completion was triggered in a parameter completion site, you have to check InternalCompletionContext.getCompletionNode() and InternalCompletionContext.getCompletionNodeParent() to see if it's a MessageSendCompletion or not. All required information should be available here.

Afterwards you have to create and return your own JavaCompletionProposals for your parameter completions.

We have build some helper classes around this for Recommenders, but I guess binding your engine too closely to Recommenders infrastructure is at the moment not intended :)

Let me know if one of these approaches is applicable. Let me know if not. Just let me know in any case :)

Best,
Marcel



On 22.02.2012, at 05:34, Cheng Zhang wrote:

> Hi,
> 
> My name is Cheng Zhang, a student who is fascinated by this interesting 
> project, Eclipse Recommenders. 
> 
> Inspired by Eclipse Recommenders and Marcel's FSE' 09 paper, my lab 
> mates and I have been developing an argument guessing tool which tries 
> to provide more sophisticated actual parameters/arguments for selected 
> API methods (if they need some arguments). But due to our limited knowledge 
> of Eclipse plug-in development, the current implementation is not standard, 
> that is, we directly modified the source code of JDT, instead of using some 
> extension points.
> 
> More specifically, we focus on the org.eclipse.jdt.ui project, which provides 
> the default parameter recommendations. We find out that 
> ParameterGuessingProposal extends JavaCompletionProposal, which 
> represents the best guess completion for each parameter of a method, 
> in org.eclipse.jdt.internal.ui.text.java package. Our modifications of default JDT 
> project are all limited in this class.
> 
> The only method we have changed is guessParameters(char[][] parameterNames), 
> in which JDT gets all the accessible local variables, selects and ranks them and 
> shows them to end users. Here we just call our recommendation engine, and 
> combine our results with default recommendations, before JDT returning these 
> to users. The context information which JDT has already prepared is enough for 
> us to perform our recommendations.
> 
> Would you please give me some suggestions on better implementation solutions? 
> I think our current solution is non-standard, uneasy to install, and thus probably 
> unacceptable for serious users.
> 
> Thanks,
> Cheng
> 
> _______________________________________________
> recommenders-dev mailing list
> recommenders-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/recommenders-dev

Back to the top