Community
Participate
Working Groups
Build Identifier: I20110613-1736 (3.7.0) If the Organize Imports functionality cannot resolve an import statement, it simply discards it. I consider this as plain wrong - preferably Eclipse should leave code it cannot process untouched. This one is especially annoying when "organize imports" is / has to be used as safe action due to project requirements, as such inconsistent states might very well be worth saving from time to time. Reproducible: Always Steps to Reproduce: 1. Create a class with some unresolvable, non-qualified type reference and an import for this type 2. Call Organize-Imports
Organize Imports cleans up your import list: it adds new ones and removes outdated ones. This is as designed and won't be changed.
(In reply to comment #1) > Organize Imports cleans up your import list: it adds new ones and removes > outdated ones. This is as designed and won't be changed. I know that this is already resolved, and I agree that this is working as designed, but I think it would be really useful to have an option to disable organizing imports if there are some compilation errors in the file. This would be handy especially in situations where you use some tools like Maven or Ivy to resolve dependencies, and this organize imports feature removes imports that are necessary if e.g. Ivy fails to download some library temporarily.
(In reply to comment #2) > (In reply to comment #1) > > Organize Imports cleans up your import list: it adds new ones and removes > > outdated ones. This is as designed and won't be changed. > > I know that this is already resolved, and I agree that this is working as > designed, but I think it would be really useful to have an option to disable > organizing imports if there are some compilation errors in the file. This would > be handy especially in situations where you use some tools like Maven or Ivy to > resolve dependencies, and this organize imports feature removes imports that > are necessary if e.g. Ivy fails to download some library temporarily. Why do you call 'Organize Imports' then? And why can't you call 'Organize Imports' again later, when the build path is correct?
(In reply to comment #3) > Why do you call 'Organize Imports' then? And why can't you call 'Organize > Imports' again later, when the build path is correct? Because I've got it enabled as a "save action", which is really useful, except in this case. But I should correct my suggestion - I think it would be useful only not to remove imports if there are some compilation issues, because I realized that organize imports needs to be triggered to add missing imports, even if there are compilation errors. My suggestion is basically to be on the safe side and remove stuff only if we can be 100% sure that it is really not needed. Thanks, Pavel
> My suggestion is basically to be on the > safe side and remove stuff only if we can be 100% sure that it is really not > needed. Makes sense. We should add a preference on the 'Organize Imports' page which by default doesn't remove unused imports if there's an unresolved type error in the CU.
Fix goes into org.eclipse.jdt.internal.corext.codemanipulation.OrganizeImportsOperation.
(In reply to comment #5) > Makes sense. We should add a preference on the 'Organize Imports' page which by > default doesn't remove unused imports if there's an unresolved type error in > the CU. Thanks Dani. This is exactly the option we are missing in our team. Pavel
*** Bug 376353 has been marked as a duplicate of this bug. ***
*** Bug 395538 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/42682
I have uploaded a change which addresses this bug by preserving unresolvable imports matching unresolved names in the compilation unit. For each unresolved name in the CU, it first attempts to preserve an unresolvable single import of the same name and, failing that, preserves all on-demand imports. It does this separately for static and for non-static unresolvable names and imports.
(In reply to John Glassmyer from comment #11) Thanks, that sounds good to me and avoids another preference.
Jay, could you please review the Gerrit patch. Thank you.
Jay: moving the review back to Markus as the changes are all in jdt.ui (there is no jdt.core change in the patch).
The Gerrit patch is waiting for review since February. Any chance to get it reviewed soon?
(In reply to Sergey Prigogin from comment #15) > The Gerrit patch is waiting for review since February. Any chance to get it > reviewed soon? Yes. I'm really sorry about the repeated moves. In M4, I'll finally be around for the whole milestone again, and I've reserved time for this and other reviews waiting in my queue.
Gerrit change https://git.eclipse.org/r/42682 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=a0135375c7f4f85b769b2a731e6e1a3574906394
Thanks for the clean patch. Released with a small fix for this case (doubly-broken static import): package xy; import static Broken; public class BreakIt { int i = Broken; }
Thank you, Markus.
Verified in eclipse-SDK-I20151207-2000-win32-x86_64.
Hmm... the fix for this bug... causes another bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=495424 Reading through the comments here it sounds like this fix comes with a preference on the "Organize imports" page to enable or disable it. But looking at that page I don't see it. Am I looking in the wrong place maybe?
(In reply to Kris De Volder from comment #21) > Reading through the comments here it sounds like this fix comes with a > preference on the "Organize imports" page to enable or disable it. But > looking at that page I don't see it. Am I looking in the wrong place maybe? No preference was added with this. See comment #12.
