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 Marcel,

On Fri, Apr 6, 2012 at 3:17 AM, Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx> wrote:
Hi Cheng,

On 05.04.2012, at 20:31, Cheng Zhang wrote:

Hi Marcel,

We will have at least two users participate Nick's user study.
Perhaps another two or three students will join in (after their Spring travel...).

Excellent! That's more we could have hoped for. I think Nick will be pleased ;)

Actually, another member from our lab have checked out several versions of Recommenders from the official site.
He is trying to implement some recommendation functions for _javascript_ by referring to the code of Recommenders :-) 
Unfortunately, he found that the code base is ever changing (maybe due to your intensive development on the project these weeks).

Oh. ;) Just let us know which parts you rely on. If we know who is using our (mostly internal) APIs, we can start stabilizing them and warn if we don't get around larger changes. 0.x versions are considered to have very "fluent" APIs and until today I assumed we are the only clients of our APIs. Just keep us posted which packages you use.

In fact, he is doing a study on the code of Recommenders. When he gets started, we will discuss with you. 
It is always helpful to us ;)
 


Besides the attempt by Juyuan, that guy tried to add the parameter recommendation to Recommenders and it seemed successful.
By now I am not quite clear how he exactly did it, but I am wondering whether it is encouraged or discouraged by you.

Is the code public available? I'm low in time until the 18.04. but I might be able to scan the code and/or ask one or two JDT pros for their comments.


I find that he just did a dirty hack in the following steps:
1) Separate from the whole code base the projects below:
    org.eclipse.recommenders.completion.rcp
    org.eclipse.recommenders.completion.rcp.chain
    org.eclipse.recommenders.completion.rcp.e37
    org.eclipse.recommenders.injection
    org.eclipse.recommenders.rcp
    org.eclipse.recommenders.utils
    org.eclipse.recommenders.utils.rcp

2) Extend the class CompletionTemplateBuilder(), override the method appendParameters(IMethod)
    He changed the method appendParameters(IMethod) from private to protected... 

3) Do a one-line modification to ChainCompletionProposalComputer.java, in method executeCallChainSearch(),
    replacing CompletionTemplateBuilder() with his own subclass.

I guess it is nothing to do with the original JDT, but more relevant to Recommenders. Right?
 
Or if somebody intends to extend the Recommenders, what kind of approach is recommended?

As written above: most parts are yet not considered to be stable APIs yet. Best will be to let us know which parts you use or intend to use. You should consider using bugzilla to let us know about APIs in use - and let us know if a change broke some parts of your code. We certainly won't rollback the change after the fact but with that feedback we'll learn what APIs are considered useful by your team and will start stabilizing this part for the future. Also feel invited to add feature request to bugzilla or provide your own patches for new functionality via Eclipse's Gerrit. Recommenders is open for contribution and participation.


Great to hear that! Our next step is to improve the code quality of our own project (code review, refactoring, testing...).
Hope we can make essential contributions to the Recommenders project in the near future (no matter they are related to Precise or not).

Best,
Cheng


Best,
Marcel

Thank you for your suggestions. They are really useful to us!

Best,
Cheng

On Fri, Apr 6, 2012 at 1:57 AM, Marcel Bruch <marcel.bruch@xxxxxxxxx> wrote:
Hi Juyuan,

On 05.04.2012, at 19:13, Juyuan Yang wrote:

Hi Marcel, 

I am a member of this parameter recommendation project. Thank you very much for your suggestions. We have tried your solution #2.

We create our own completion engine, using org.eclipse.jdt.ui.javaCompletionProposalComputer extension point. To use this extension point, it seems that we have to implement both method recommendation and parameter recommendation in this function:
List<ICompletionProposal> computeCompletionProposals(ContentAssistInvocationContext context, IProgressMonitor monitor);

We don't want to spend much time on the method recommendation, so we just reuse the code in JavaAllCompletionProposalComputer, and make our PreciseCompletionProposalComputer extends it to get JDT default method and paramter recommendations. Then we reuse the code in ParameterGuessingProposal, and slightly change the function guessParameters(char[][] parameterNames), to get recommendations from Precise and combine them with JDT default recommendations. Besides, we also copy essential related codes from JDT to support these code extensions (such like, FillArgumentNamesCompletionProposalCollector, AbstractJavaCompletionProposal and so on). 

In summary, we separate the code about JDT default method and parameter recommendation from org.eclipse.jdt.ui, copy them and make some essential changes to implement our code completion extension.

We have a question when reusing the codes from JDT. Some classes depend on some internal classes in JDT (package is like org.eclipse.jdt.internal.**), so when we import those internal class, Eclipse says it is discouraged access and suggests us to add @SuppressWarnings("restriction") in front of the class. We have added the SuppressWarnings, and our plugin seems to work well now. So that might not make any sense?

well, without looking at your code, it's hard to say. As a general rule of thumb, however, it is okay for those things _you_ (we all) do to rely on internal APIs. We all extend JDT in a way that was not foreseen when JDT APIs were designed. It may be the case that there are smarter solutions that archive the same results with less code. But in general you will rely on internals...

There are few moments every year you have to check if your code still works - before every new (service) release. But with a nice test suite that builds against the latest integration builds you will know early if something won't work with the next version of JDT.

Always keep in mind that JDT may make some APIs public upon request. Thus, if you need access to some fields or methods or classes that are only package visible, for instance, it may be easy to change them. Just keep me posted.

Regards,
Marcel


P.S.: Please consider participating in Nick's user study. We'll do so for your future studies too. OK, I stop nagging now ;)


Best,
Juyuan

在 2012年2月22日 下午3:00,Marcel Bruch <marcel.bruch@xxxxxxxxx>写道:
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




_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev


_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

Thanks,
Marcel



_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev



Back to the top