Community
Participate
Working Groups
Given this code, where ArrayList is imported and List is not yet imported: List<String> l = new ArrayList<String>(); Invoking quick fix on List shows the following proposals (in that order): * Import 'List' (java.awt) * Import 'List' (java.util) There are two issues with the first entry: 1. java.awt.List is not generic, therefore invalid 2. java.awt.List is not a super-type of java.util.ArrayList, therefore invalid So the only choice that does not produce an error is java.util.List. Ideally, when having the "Organize Imports" save action configured, it should be imported automatically, not requiring further user input. In case the quick fix is invoked, invalid choices should either be not listed or be listed after the valid choices. See also ide-dev mailing list thread: https://dev.eclipse.org/mhonarc/lists/ide-dev/msg00072.html
*** Bug 395500 has been marked as a duplicate of this bug. ***
a few ideas how to make this more flexible: The proposal sorter is hard-coded in JavaCorrectionProcessor. Since it works on IJavaCompletionProposals it *may* reuse the configured sorter for content assist. This does not fix the issue but opens that mechanism for new extensions. But it would probably be better to have a new base class for that. With a new base class, the sorter should get access to the AssistContext to compute the facts it needs to sort proposals properly. Third (here the opinions way diverge), the sorter may get access to the complete list of proposals to filter the unwanted / unlikely proposals. Even if unmodifiable, a list of available assists would be helpful. AFAICT, all changes are local to org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.computeQuickAssistProposals(IQuickAssistInvocationContext) To me this change makes sense. Would JDT accept this solution as contribution for 4.4 and 4.3.2?
Marcel, why not create a Gerrit change request? I think with code it's easier for JDT to comment on the proposal.
Because (i) it needs some time to implement it, (ii) there are different styles how to iplement it, (iii) some features are JDT might reject/dislike, and (iv) JDT people (like Dani I guess) know quickly if this is the way they would like it to be and accept.
I have good experience with patches via Gerrit. The team can comment on styling issues.
Comment 0 describes two different issues: - Organize Imports doesn't detect and filter unappropriated types (generic vs. non-generic and assignment mismatches) - Quick Fix does not rate perfect matches higher and there is a third case which is interesting: content assist - it has the same sorting issue as the Quick Fix. If we improve/fix content assist in JDT Core to set better relevances, it will also fix the Quick Fix, because those proposals are also computed via content assist. No new extensions or APIs are needed to achieve that. I suggest to make two bugs out of this one.
(In reply to Dani Megert from comment #6) > I suggest to make two bugs out of this one. Done, I created two bugs and made them block this one (but this could also be closed). > Comment 0 describes two different issues: > - Organize Imports doesn't detect and filter unappropriated types (generic > vs. > non-generic and assignment mismatches) See bug 419618. > - Quick Fix does not rate perfect matches higher > and there is a third case which is interesting: content assist - it has the > same sorting issue as the Quick Fix. If we improve/fix content assist in JDT > Core to set better relevances, it will also fix the Quick Fix, because those > proposals are also computed via content assist. See bug 419619. > No new extensions or APIs are needed to achieve that. Good to hear!
(In reply to Dani Megert from comment #6) > If we improve/fix content assist in JDT > Core to set better relevances, it will also fix the Quick Fix, because those > proposals are also computed via content assist. It looks like there is no code yet that provides access to RHS of the assignment in CompletionEngine. The referenceContext does not provide that information (only field declarations but not it's initializations). Any idea how this should be solved? Should the type resolution consider the import statements (which are available) and do a "is-proposed-type-a-super-type-of-any-imported-type" thingy?
(In reply to Marcel Bruch from comment #8) > (In reply to Dani Megert from comment #6) > It looks like there is no code yet that provides access to RHS of the > assignment in CompletionEngine. The referenceContext does not provide that > information (only field declarations but not it's initializations). Any idea > how this should be solved? > > Should the type resolution consider the import statements (which are > available) and do a "is-proposed-type-a-super-type-of-any-imported-type" > thingy? I've copied this over to bug 419619.
Closed as INVALID as we have two independent bugs to track the issues.
