Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Java Development Tools (JDT) » QuickfixProcessor vs. Eclipse UI Quick Fix(They don't match!)
QuickfixProcessor vs. Eclipse UI Quick Fix [message #671778] Thu, 19 May 2011 00:42 Go to next message
Kivanc Muslu is currently offline Kivanc MusluFriend
Messages: 153
Registered: November 2010
Senior Member
Hi all,

I am trying to get the quick fixes offered for a compilation error both using Eclipse API and going through the user interface and clicking on the quick fix icon. For the following code example:

package slides;

@SuppressWarnings("unused")
public class SlideExamples
{
    private Str name;
    
    public void m1() { 
        String temp = name; 
    }
    
    public void m2() { 
        name = "Hello World"; 
    }
    
    public String m3() { 
        return name; 
    }
    
    public void m4(String s) {}
    
    public void m5() { 
        m4(name); 
    }
}


when I click for the first quick fix (i.e., Str name), I get 11 proposals. However if I call:
// Assume that context and locations are correct.
IQuickFixProcessor qfProcessor_ = new QuickFixProcessor();
            IJavaCompletionProposal [] proposals = qfProcessor_.getCorrections(context, locations);
            return proposals;

I get 10 proposals.

For the remaining compilation errors (i.e., uses of name), when I click in the UI, I get 15 proposals, from the eclipse API code, I get 13 proposals.

Does anybody know why this happens (i.e., some proposals are lost)? I am pretty sure that the 'context' and 'locations' apssed to QuickFixProcessor are correct since all the proposals I get from eclipse API matches to the ones I get from the UI (i.e., there are no extras). However for some reason I cannot get some of the proposals offered by the UI.

Is there another way (more reliable) to get the proposals offered for that quick fix?

Thanks in advance, best regards,
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #671793 is a reply to message #671778] Thu, 19 May 2011 01:38 Go to previous messageGo to next message
Deepak Azad is currently offline Deepak AzadFriend
Messages: 543
Registered: July 2009
Senior Member
On 5/19/2011 6:12 AM, Kivanc Muslu wrote:
> Hi all,
> I am trying to get the quick fixes offered for a compilation error both
> using Eclipse API and going through the user interface and clicking on
> the quick fix icon. For the following code example:
>
>
> package slides;
>
> @SuppressWarnings("unused")
> public class SlideExamples
> {
> private Str name;
> public void m1() { String temp = name; }
> public void m2() { name = "Hello World"; }
> public String m3() { return name; }
> public void m4(String s) {}
> public void m5() { m4(name); }
> }
>
>
> when I click for the first quick fix (i.e., Str name), I get 11
> proposals. However if I call:
>
> // Assume that context and locations are correct.
> IQuickFixProcessor qfProcessor_ = new QuickFixProcessor();
> IJavaCompletionProposal [] proposals =
> qfProcessor_.getCorrections(context, locations);
> return proposals;
>
> I get 10 proposals.
>
> For the remaining compilation errors (i.e., uses of name), when I click
> in the UI, I get 15 proposals, from the eclipse API code, I get 13
> proposals.

The extra proposals in the UI should be 'Rename' and 'Rename in Workspace'.

> Does anybody know why this happens (i.e., some proposals are lost)? I am
> pretty sure that the 'context' and 'locations' apssed to
> QuickFixProcessor are correct since all the proposals I get from eclipse
> API matches to the ones I get from the UI (i.e., there are no extras).
> However for some reason I cannot get some of the proposals offered by
> the UI.

The reason for the discrepancy is that QuickFixProcessor is not the only
processor being used from the UI :)

> Is there another way (more reliable) to get the proposals offered for
> that quick fix?
>
> Thanks in advance, best regards,

In o.e.jdt.ui the proposals are collected by
org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #754718 is a reply to message #671793] Fri, 04 November 2011 01:31 Go to previous messageGo to next message
Kivanc Muslu is currently offline Kivanc MusluFriend
Messages: 153
Registered: November 2010
Senior Member
Hi Deepak,

Thanks for the answer. I tried using JavaCorrectionProcessor as following:
        ArrayList <IJavaCompletionProposal> proposals = new ArrayList <IJavaCompletionProposal>();
        IInvocationContext context = ...
        IProblemLocation [] locations ...
        JavaCorrectionProcessor.collectCorrections(context, locations, proposals);


However, I still get 13 proposals for the remaining problem locations (or markers). Do you think that UI is running some other processor on top of this? Or I am calling a wrong method in JavaCorrectionProcessor?

Thanks,
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #754722 is a reply to message #754718] Fri, 04 November 2011 02:30 Go to previous messageGo to next message
Deepak Azad is currently offline Deepak AzadFriend
Messages: 543
Registered: July 2009
Senior Member
On 11/4/2011 7:01 AM, Kivanc Muslu wrote:
> Hi Deepak,
> Thanks for the answer. I tried using JavaCorrectionProcessor as following:
>
> ArrayList <IJavaCompletionProposal> proposals = new ArrayList
> <IJavaCompletionProposal>();
> IInvocationContext context = ...
> IProblemLocation [] locations ...
> JavaCorrectionProcessor.collectCorrections(context, locations, proposals);
>
>
> However, I still get 13 proposals for the remaining problem locations
> (or markers). Do you think that UI is running some other processor on
> top of this? Or I am calling a wrong method in JavaCorrectionProcessor?
>
> Thanks,

Can you tell me the name of the proposals which are extra in the UI?

Some Quick *Assists* are also offered in case of errors as a quick fix.
The method which collects both 'corrections' and 'assists' is -
org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.collectProposals(IInvocationContext,
IAnnotationModel, Annotation[], boolean, boolean,
Collection<IJavaCompletionProposal>)

PS: This is you http://www.kivancmuslu.com/, right?

I like the idea of 'Smart Quick Fixes' described at
http://www.kivancmuslu.com/Quick_Fix_Scout/Evaluator.html. It could be a
nice addition to JDT.

How did you implement this? I am wondering if it would be possible for
you to contribute this back to JDT...
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #754724 is a reply to message #754722] Fri, 04 November 2011 03:13 Go to previous messageGo to next message
Kivanc Muslu is currently offline Kivanc MusluFriend
Messages: 153
Registered: November 2010
Senior Member
Hi Deepak,

Thanks for the answer. The proposals I only get in the UI are the following:
Change to 'NA' (javax.print.attribute.standard.MediaSize)
and
Change to 'Name' (java.util.jar.Attributes)

I have also uploaded a screen shot that shows them in action (i.e., I put N/A on the left since I couldn't process them in the background).

Yes, that is me and I have been working on this project about 1 year. Due to limited API functionality, my current implementation mostly relies on the hooks I have put into org.eclipse.jface.text plug-in (i.e., I modify the source to call into my plug-ins, recompile it as a patch and put in Eclipse dropins folder).

I am sure that internal Eclipse has all the information (and maybe even more than I could come up with) to implement this feature. The main idea behind that can be summarized as following:
1- Create a background copy of the active project developer is working on, keep it in sync at all times.
2- Whenever a new compilation error appears, get all proposals offered for that compilation error, apply the proposal to the copy, get the number of compilation errors (in the future state), undo the application.
Just for updating the dialog with additional information: When user clicks, add the pre-computed information.
For smart quick fixes (global best proposals), when the whole project is analyzed, sort the proposals with respect to the number of compilation errors that will remain and if the best one is not offered for the quick fix that the developer has chosen, add it to the top of the list.

Currently, the biggest problems are the following: minor synchronization issues (in rare cases that I cannot understand) between the original and copy project, the fact that the copy project also lives in the same workspace (i.e., it clutters the whole workspace with its information and updating the quick fix dialog (most of my hooks are for this: getting the moment it is updated by the Eclipse and re-writing the information and data)).

I would be extremely happy to share the project source with you (or JDT team) and/or try to contribute this back to JDT in a way you think appropriate (if it is at all). Just let me know what I can do and how I can help.

Thanks a lot!
  • Attachment: JDT_QFD.png
    (Size: 30.07KB, Downloaded 183 times)
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #754731 is a reply to message #754724] Fri, 04 November 2011 05:45 Go to previous messageGo to next message
Deepak Azad is currently offline Deepak AzadFriend
Messages: 543
Registered: July 2009
Senior Member
On 11/4/2011 8:43 AM, Kivanc Muslu wrote:
> Hi Deepak,
>
> Thanks for the answer. The proposals I only get in the UI are the following:
> Change to 'NA' (javax.print.attribute.standard.MediaSize)
> and
> Change to 'Name' (java.util.jar.Attributes)
>
> I have also uploaded a screen shot that shows them in action (i.e., I put N/A on the left since I couldn't process them in the background).
The fact that you call collectCorrections(...) instead of
collectProposals(...) does not matter in this case. (Though you may
still want to switch to collectProposals(..)).

You can try debugging the code in UnresolvedElementsSubProcessor, and
see why the two types (NA and Name) are not found when you get quick
fixes via API.

Do you compute the quick fixes via API on the copy of the project and
compare this with the result obtained on the actual project? Maybe
something is different between the two projects...

> Yes, that is me and I have been working on this project about 1 year. Due to limited API functionality, my current implementation mostly relies on the hooks I have put into org.eclipse.jface.text plug-in (i.e., I modify the source to call into my plug-ins, recompile it as a patch and put in Eclipse dropins folder).
>
> I am sure that internal Eclipse has all the information (and maybe even more than I could come up with) to implement this feature. The main idea behind that can be summarized as following:
> 1- Create a background copy of the active project developer is working on, keep it in sync at all times.
> 2- Whenever a new compilation error appears, get all proposals offered for that compilation error, apply the proposal to the copy, get the number of compilation errors (in the future state), undo the application.
> Just for updating the dialog with additional information: When user clicks, add the pre-computed information.
> For smart quick fixes (global best proposals), when the whole project is analyzed, sort the proposals with respect to the number of compilation errors that will remain and if the best one is not offered for the quick fix that the developer has chosen, add it to the top of the list.
>
> Currently, the biggest problems are the following: minor synchronization issues (in rare cases that I cannot understand) between the original and copy project, the fact that the copy project also lives in the same workspace (i.e., it clutters the whole workspace with its information and updating the quick fix dialog (most of my hooks are for this: getting the moment it is updated by the Eclipse and re-writing the information and data)).
>
> I would be extremely happy to share the project source with you (or JDT team) and/or try to contribute this back to JDT in a way you think appropriate (if it is at all). Just let me know what I can do and how I can help.

A lot of your questions make sense now! (I always wondered why you
wanted to make a copy of a project)

I think the idea of suggesting a quick fix at another location is nice,
however keeping a copy of a project is a no go for JDT. I must add that
I do not like the quick fixes JDT offers in the example you mentioned,
things can be improved here but I do not have a good solution in mind
for JDT.

Do you know other scenarios, besides unresolved elements, where offering
a quick fix from another location helps?
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #754738 is a reply to message #754731] Fri, 04 November 2011 06:28 Go to previous messageGo to next message
Kivanc Muslu is currently offline Kivanc MusluFriend
Messages: 153
Registered: November 2010
Senior Member
Hi Deepak,

Quote:
The fact that you call collectCorrections(...) instead of
collectProposals(...) does not matter in this case. (Though you may
still want to switch to collectProposals(..)).

Would collectProposals (i.e., the extra assists) even decrease the number of compilation errors? I always thought that assists were for mainly warnings or for things like 'Rename in place', 'Rename in workspace' where the auto-action could not fix any compilation error at all.

Quote:

You can try debugging the code in UnresolvedElementsSubProcessor, and
see why the two types (NA and Name) are not found when you get quick
fixes via API.

I will try this thanks.

Quote:

Do you compute the quick fixes via API on the copy of the project and
compare this with the result obtained on the actual project? Maybe
something is different between the two projects...

I normally do all my analysis in the copy project, however I also thought that this might be a problem due to copy and also tried getting proposals offered for the original project. The proposals I get from QuickFixProcessor (or JavaCorrectionProcessor) were also not complete (i.e., missing the same 2 proposals). That is why I still think that UI (somehow) adds those 2 proposals later after getting the proposals from JDT. (i.e., JDT does not have those proposals maybe?)

Quote:

A lot of your questions make sense now! (I always wondered why you
wanted to make a copy of a project)

Sorry. I guess I should have mentioned this before. However, I generally don't want to scare people with the details of the project if I can communicate my problem otherwise.

Quote:

I think the idea of suggesting a quick fix at another location is nice,
however keeping a copy of a project is a no go for JDT. I must add that
I do not like the quick fixes JDT offers in the example you mentioned,
things can be improved here but I do not have a good solution in mind
for JDT.

I agree. Since I started looking at Quick Fixes differently due to my research, I also got a couple of different quick fix proposals, especially for places where it seems that a quick fix could easily be offered but not offered.
However, to Eclipse's and JDT's defense, I still think that Quick Fix in Eclipse is quite powerful tool. Before starting my project I was using it a lot and if Eclipse wouldn't have offered this many different quick fixes with multiple semantic change choices, I don't think a speculative analysis would make sense. That is why I am still grateful Smile

Quote:

Do you know other scenarios, besides unresolved elements, where offering
a quick fix from another location helps?

It turns out that I actually haven't think about this before. However, after a little thinking and playing on the Eclipse, I come up with the following example. I have attached the pictures for the complete code, proposals offered with and without QFS (i.e., my analysis). The examples I have might seem unlikely, however I especially try to keep them as small as possible, so that the essence would be clear. I think that in complex situations such problems might arise.
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #754768 is a reply to message #754738] Fri, 04 November 2011 09:30 Go to previous messageGo to next message
Deepak Azad is currently offline Deepak AzadFriend
Messages: 543
Registered: July 2009
Senior Member
On 11/4/2011 11:58 AM, Kivanc Muslu wrote:

>> The fact that you call collectCorrections(...) instead of
>> collectProposals(...) does not matter in this case. (Though you may
>> still want to switch to collectProposals(..)).
>
> Would collectProposals (i.e., the extra assists) even decrease the number of compilation errors? I always thought that assists were for mainly warnings or for things like 'Rename in place', 'Rename in workspace' where the auto-action could not fix any compilation error at all.

public String m3() {
name; //error
}

- Place caret in "name" and press Ctrl+1
- select 'Assign to a new local variable'
=> the error goes away

Take a look at QuickAssistProcessor.getAssists(IInvocationContext,
IProblemLocation[]) to see which assists are offered in case of an error.

>
> Quote:
>> You can try debugging the code in UnresolvedElementsSubProcessor, and
>> see why the two types (NA and Name) are not found when you get quick
>> fixes via API.
>
> I will try this thanks.
>
> Quote:
>> Do you compute the quick fixes via API on the copy of the project and
>> compare this with the result obtained on the actual project? Maybe
>> something is different between the two projects...
>
> I normally do all my analysis in the copy project, however I also thought that this might be a problem due to copy and also tried getting proposals offered for the original project. The proposals I get from QuickFixProcessor (or JavaCorrectionProcessor) were also not complete (i.e., missing the same 2 proposals). That is why I still think that UI (somehow) adds those 2 proposals later after getting the proposals from JDT. (i.e., JDT does not have those proposals maybe?)
Try to debug UnresolvedElementsSubProcessor for both the cases -
collecting quick fixes via API and collecting quick fixes from UI. The
quick fixes should be from UnresolvedElementsSubProcessor only...

>> Do you know other scenarios, besides unresolved elements, where offering
>> a quick fix from another location helps?
>
> It turns out that I actually haven't think about this before. However, after a little thinking and playing on the Eclipse, I come up with the following example. I have attached the pictures for the complete code, proposals offered with and without QFS (i.e., my analysis). The examples I have might seem unlikely, however I especially try to keep them as small as possible, so that the essence would be clear. I think that in complex situations such problems might arise.
I think it could be useful to compile a list of such scenarios, it would
validate the usefulness of the feature, and also highlight the
deficiencies in quick fixes provided by JDT.
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #755458 is a reply to message #754738] Tue, 08 November 2011 15:10 Go to previous messageGo to next message
Deepak Azad is currently offline Deepak AzadFriend
Messages: 543
Registered: July 2009
Senior Member
On 11/4/2011 11:58 AM, Kivanc Muslu wrote:
> It turns out that I actually haven't think about this before. However, after a little thinking and playing on the Eclipse, I come up with the following example. I have attached the pictures for the complete code, proposals offered with and without QFS (i.e., my analysis). The examples I have might seem unlikely, however I especially try to keep them as small as possible, so that the essence would be clear. I think that in complex situations such problems might arise.

Kivanc, if you invoke quick fix on the abstract method instead of the
class, JDT will propose 2 quick fixes
1. to remove the abstract modifier from the method
2. to make the type abstract
Now the 2nd quick fix can be thought of as a quick fix at another
location. When quick fix is invoked on the type I think it makes sense
to show only the quick fix which is offered by JDT i.e. Make the type
abstract (think of the case when there are many abstract methods)

Point is, quick fixes in JDT are implemented in such a way so as to
solve as many problems as possible. At least that is the intent, though
we may fail sometimes, for example in case of unresolved elements where
the quick fixes offered can be improved as your work has shown. But so
far I am struggling to come up with other examples.
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #755595 is a reply to message #755458] Tue, 08 November 2011 21:43 Go to previous messageGo to next message
Kivanc Muslu is currently offline Kivanc MusluFriend
Messages: 153
Registered: November 2010
Senior Member
Hi Deepak,

I understand your point and concerns, however the fact that the extra proposals I add to the type itself also fixes the compilation error at that location (which is our metric to define if it is useful or not), seems still enough for me to add proposal 'Remove abstract modifier' to that location.

The way I see proposals is that they are produced to get rid of that local compilation error. In this example, another proposal (at another location) can also fix that local compilation error, so I still think it should be good to include for the developers. It also supports your saying that quick fixes are generated to fix as much compilation errors as possible (i.e., in this case the normal offering can only fix one compilation error), however the one I extract from the remaining compilation errors and add to top fixes all of them). If I missed something, please let me know.

Also here is another example for you Smile (again I am open to discussion) The screen-shots are attached. In this example, you can think the smart proposals as representing the following: doing an analysis inside the try block and seeing that there is a method used there. So the compilation error in the catch part can also be fixed by changing this method's signature by letting it throw the same exception that is caught (in our case MyException). If you also go and look at the method, you see that it already throws the same exception (however missing the throw declaration). So again, by extracting that proposal from the method to catch clause, I am hitting two birds with one stone (I hope Smile)
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #755613 is a reply to message #755595] Wed, 09 November 2011 01:29 Go to previous messageGo to next message
Deepak Azad is currently offline Deepak AzadFriend
Messages: 543
Registered: July 2009
Senior Member
On 11/9/2011 3:13 AM, Kivanc Muslu wrote:

> It also supports your saying that quick fixes are generated to fix as much compilation errors as possible (i.e., in this case the normal offering can only fix one compilation error), however the one I extract from the remaining compilation errors and add to top fixes all of them). If I missed something, please let me know.
A more complete statement would be - Quick fixes are offered to fix as
many compilation errors as possible while making sure that the fix
offered is the 'right' one.

I still think that the 'Remove abstract modifier' example is not a great
one from a user's point of view.

> Also here is another example for you :) (again I am open to discussion) The screen-shots are attached. In this example, you can think the smart proposals as representing the following: doing an analysis inside the try block and seeing that there is a method used there. So the compilation error in the catch part can also be fixed by changing this method's signature by letting it throw the same exception that is caught (in our case MyException). If you also go and look at the method, you see that it already throws the same exception (however missing the throw declaration). So again, by extracting that proposal from the method to catch clause, I am hitting two birds with one stone (I hope :))

Now this is a better example! It goes significantly beyond what JDT
currently does and what JDT will probably do for the foreseeable future :)
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #755631 is a reply to message #755613] Wed, 09 November 2011 06:47 Go to previous messageGo to next message
Kivanc Muslu is currently offline Kivanc MusluFriend
Messages: 153
Registered: November 2010
Senior Member
Hi Deepak,

I understand your argument with respect to user's point of view. Thanks for all the feedback!

Quote:

Now this is a better example! It goes significantly beyond what JDT
currently does and what JDT will probably do for the foreseeable future Smile

Wow, this is great to hear (especially from you)! As I mentioned we also realized the power of smart proposals (a.k.a global best proposals), so this is fairly a new topic for us that we are investigating. I will try to come up with other meaningful examples for you and try to get your feedback on them. And who knows, maybe JDT can figure out another way (not through speculative analysis) to include those in the future Smile

By the way, here is another example over sub-typing (kind of multiple inheritance - I know Java does not have multiple inheritance, however you could simulate similar sub-typing hierarchy by implementing multiple classes, as Eclipse source does all the time Smile)

The screen-shots are attached and the summary is as following: The developer mis-types the return type of a method. The method used in two different places and the return type is assigned to two different types (A and B). Eclipse by default only offers to change the return type to 'A' and 'B' respectively in the related places. However, the method returns D, which normally implements both. So, normally returning 'D' would fix all errors and this is normally offered in the method itself. However, at this moment, JDT does not try to look for the super-types of the left-hand-side of the assignment. With my current analysis, I can extract 'Change method return type to D' proposals from the method and offer it inside the other method (for both instances of usage). As usual, I appreciate your feedback, so let me know, what you think about this (by the way, maybe at least this can be implemented quite easily in JDT).
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #755698 is a reply to message #755631] Wed, 09 November 2011 10:36 Go to previous messageGo to next message
Deepak Azad is currently offline Deepak AzadFriend
Messages: 543
Registered: July 2009
Senior Member
On 11/9/2011 12:17 PM, Kivanc Muslu wrote:
> The screen-shots are attached and the summary is as following: The developer mis-types the return type of a method. The method used in two different places and the return type is assigned to two different types (A and B). Eclipse by default only offers to change the return type to 'A' and 'B' respectively in the related places. However, the method returns D, which normally implements both. So, normally returning 'D' would fix all errors and this is normally offered in the method itself. However, at this moment, JDT does not try to look for the super-types of the left-hand-side of the assignment. With my current analysis, I can extract 'Change method return type to D' proposals from the method and offer it inside the other method (for both instances of usage). As usual, I appreciate your feedback, so let me know, what you think about this (by the way, maybe at least this can be implemented quite easily in JDT).
This example is also reasonable. In essence you take into account all
errors in a project/file while proposing quick fixes for an error.
Currently, we don't do that in JDT. But I think the idea is useful, at
least in the 2 scenarios you have shown here. (...and I would really
like to see more concrete examples where such an approach is useful)

However, as I said before copying a project is a no go for JDT. Also do
you apply every quick fix on every error in the file/project? How is the
performance of your code, i.e. how responsive are your quick fixes?

It might be better to
- first map/find relationships between various errors (each error has a
unique id). Find out how an error relates to others e.g the two errors
in case of the abstract type/method example. (Take a look at
org.eclipse.jdt.core.compiler.IProblem for the list of all problem markers)
- then while evaluating a quick fix check if there are any related
errors in the same file (or a package or project, though I would
restrict to file to begin with).
- consider only the related errors, and try to offer quick fixes that
make sense. This should reduce the false positives or in other words
improve quality of quick fixes offered.
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #755849 is a reply to message #755698] Wed, 09 November 2011 19:47 Go to previous messageGo to next message
Kivanc Muslu is currently offline Kivanc MusluFriend
Messages: 153
Registered: November 2010
Senior Member
Hi Deepak,

Sorry I guess I wasn't clear. I was trying to say that JDT team (or later me) can try to implement the ideas coming from this discussion later on with other techniques. For example, for my latest instance, the JDT can offer also changing the method return type to the super classes of the left hand-side (it does not do this currently), which would be a brute-force approach. However, as you said, this would also introduce noise (i.e., maybe too many proposals). So, maybe JDT can do a quick analysis on the other compilation errors first (just looking to see if this method return also creates another compilation error), if so take account both left hand sides of the assignment and if they are different offer the super-class of both (if available). This is of course just a workaround for that instance, but you could think other things for the other examples too (I guess).

Just to answer your questions. As I mentioned, QFS was a research project for me where we wanted to see (and still trying) the effect of speculative analysis on user decisions for quick fix proposals. The ultimate goal is to be able to give the users extra information about future states (i.e., the number of compilation errors that would happen), so that they can make better/faster decisions.

Speculative analysis inherently needs copy projects to create future versions and analyze them. Currently I am working on one copy for speculation, in theory this can be as much as the number of proposals in a project (i.e., for parallelization). As a research prototype, our fist goal is to really see if this makes any difference at all, therefore currently we weren't on to performance that much. On my recently new laptop (i5 core 2.4 ghz), I almost see no delay for speculative information for up to 5K projects. One of my friends use a slower laptop, where the speculation delay is more visible.

The way I have currently integrated the speculative analysis never blocks Quick Fix Dialog. When user activates the quick fix dialog, if the speculation is not completed, then user sees the default Eclipse offerings (as s/he would have). If the speculation is complete (or user waits for it), the dialog is updated (i.e., augmented and re-ordered) with extra information and redrawn.

I do apply all proposals over the project. This might seem extreme, however applying a proposal to a copy is generally applying a very small delta and with the great incremental compiler of eclipse, this is almost nothing. When I analyzed the bottle-neck of the program, I realized that I spent 75% of my time on retrieving the proposals offered by Eclipse (i.e., using QuickFixProcessor.getCorrections). I still haven't analyzed what is happening inside this method internally in Eclipse though.

All in all, I agree that creating copy projects is not the only way to generate smart (aka global best) proposals. Global best proposals were just a side product of my initial research. Speculation seems to be one well-defined way to generate them. I totally understand JDT's concern on performance, etc., and as I (and also you) mentioned, I believe there are other ways. However, at the moment, I have to continue with speculative analysis Smile

I will try to keep you posted as I find more scenarios where global proposals might be helpful. Thanks!
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #755983 is a reply to message #755849] Thu, 10 November 2011 11:55 Go to previous messageGo to next message
Deepak Azad is currently offline Deepak AzadFriend
Messages: 543
Registered: July 2009
Senior Member
Kivanc Muslu wrote on Wed, 09 November 2011 14:47

I was trying to say that JDT team (or later me) can try to implement the ideas coming from this discussion later on with other techniques.


Definitely! In my last comment I was just trying to think of an alternative implementation that might be more suited to JDT Smile

The numbers are surprising! I expected that there would be a delay if all quick fixes are applied on all the errors in a project. Glad that JDT code is fast!
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #755990 is a reply to message #755983] Thu, 10 November 2011 12:26 Go to previous messageGo to next message
Deepak Azad is currently offline Deepak AzadFriend
Messages: 543
Registered: July 2009
Senior Member
FYI: I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=363459 to fix/improve the unresolved element case.
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #756423 is a reply to message #755990] Sun, 13 November 2011 07:26 Go to previous messageGo to next message
Kivanc Muslu is currently offline Kivanc MusluFriend
Messages: 153
Registered: November 2010
Senior Member
Hi Deepak,

Quote:
The numbers are surprising! I expected that there would be a delay if all quick fixes are applied on all the errors in a project. Glad that JDT code is fast!

Indeed they are. I was also very shocked when I saw the performance of incremental builder, it is unbelievable! As I mentioned only real slow down I have at the moment is due to the retrieval of proposal from the QuickFixProcessor. I haven't looked at the source code yet, however I guess it goes through all registered CorrectionProcessors and asks them if they have a fix for the current compilation error. If the number of different things it needs to iterate is long, maybe that is the reason (just a guess).

Quote:
FYI: I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=363459 to fix/improve the unresolved element case.

Excellent! Thanks a lot. Again, please let me know if I can be of any help (even about the implementation, though I don't think that there is a confirmed solution yet).
Re: QuickfixProcessor vs. Eclipse UI Quick Fix [message #756431 is a reply to message #756423] Sun, 13 November 2011 10:20 Go to previous message
Deepak Azad is currently offline Deepak AzadFriend
Messages: 543
Registered: July 2009
Senior Member
> Indeed they are. I was also very shocked when I saw the performance of
> incremental builder, it is unbelievable! As I mentioned only real slow
> down I have at the moment is due to the retrieval of proposal from the
> QuickFixProcessor. I haven't looked at the source code yet, however I
> guess it goes through all registered CorrectionProcessors and asks them
> if they have a fix for the current compilation error. If the number of
> different things it needs to iterate is long, maybe that is the reason
> (just a guess).
If it becomes a problem for you, please open a bug. You can also share
the profiling data (on the basis on which you said that this takes 75%
time).
Previous Topic:Call JUnit Plugin from other Eclipse Plugin
Next Topic:Shortcuts for Project Explorer navigation
Goto Forum:
  


Current Time: Tue Mar 19 10:17:28 GMT 2024

Powered by FUDForum. Page generated in 0.04034 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top