Community
Participate
Working Groups
M4 added an import package quick fix which is sometimes useful, BUT the quick fix is at the top of the list and so pushes the import-class quick fix down. Since import-class is nearly always a better fix, it is very irritating that it is no longer at the top.
Can you post an example? If I remove the import package for a type, I do not get a quick fix to import the class. I tried with com.ibm.icu.MessageFormat and the class import for java.text.MessageFormat outranks the import package quickfix.
Created attachment 226654 [details] Screenshot It took some time for the problem to re-occur but attached shows it. I've also seen a double add to bundles, add to packages hiding the import.
In the example, the add is clearly a bad fix, since it is already imported. Perhaps it's a side effect of the much slower (? since M4) refresh rate of Imports and error messages. On M5 the editor seems even slower than on M4.
Created attachment 226997 [details] A worse example In the attached example the Import is pushed down by six Add entries so that the Import is not even visible without scrolling or resizing.
Created attachment 227851 [details] A wicked example Screen shot shows java.awt.List prominently but java.util.List demoted.
No idea when or if I'll have time to investigate this. It doesn't happen consistently for me, but when it shows up it is very confusing (in my case I had 3 possible Node classes that could be imported, 2 show up first, but the one I care about shows up after the package import options).
I had one yesterday where the import was on the eighth line and so off screen. The entries are there but not in the right order, and I presume that you have checked the sorting code for recent changes, so presumably the problem is a timing issue. The problem entries are added after quite a few seconds once inter-project dependencies have been updated. Perhaps this late update is no longer using a correct sorting criterion.
While looking at a different problem it occurred to me that this could be because of differing relevance in the resolution. PDE is always using a hard coded relevance of 16. If JDT proposal relevance can change, the results might show up higher or lower than the PDE proposals.
(In reply to comment #8) > While looking at a different problem it occurred to me that this could be > because of differing relevance in the resolution. PDE is always using a > hard coded relevance of 16. If JDT proposal relevance can change, the > results might show up higher or lower than the PDE proposals. But that can't explain an Import appearing as suggestions 1 and 4 wrapping other things at two and three. I still strongly suspect a concurrency issue.
Created attachment 235255 [details] the worst example The quick fix popup in the Java editor has been messed up since I upgraded to Kepler. Strange ordering and having to scroll is bad enough. In the attached screenshot, it offers two un-named import choices. You have to blindly pick one, and if it was wrong pick the other. Pretty bad.
(In reply to Paul Allen from comment #10) > Created attachment 235255 [details] > the worst example > > The quick fix popup in the Java editor has been messed up since I upgraded > to Kepler. Strange ordering and having to scroll is bad enough. In the > attached screenshot, it offers two un-named import choices. You have to > blindly pick one, and if it was wrong pick the other. Pretty bad. The problem in your screenshot is unrelated to this bug. The import quickfixes are provided by JDT. PDE provides the quick fixes to add packages or bundles to your bundle manifest.
(In reply to Paul Allen from comment #10) > Created attachment 235255 [details] > the worst example > > The quick fix popup in the Java editor has been messed up since I upgraded > to Kepler. Strange ordering and having to scroll is bad enough. In the > attached screenshot, it offers two un-named import choices. You have to > blindly pick one, and if it was wrong pick the other. Pretty bad. That's bug 393602.
I tried with 4.4 M6 and there the "normal" imports currently appear consistently before the classpath fixes. To make progress on this bug we'll need to have reproducible steps.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
The problem still persists and arguably it is now even worse since the background computations often take so long that it is necessary to re-request quick fixes to get an up to date list. If someone can point me at some sensible places to set a breakpoint, I can try to investigate and maybe identify which project is corrupting JDT.
