Community
Participate
Working Groups
The way in which imports are sorted into "import groups" in Organize Imports is poorly documented and should be reconsidered. The Organize Imports configuration page says the following: "Define the sorting order of import statements. A package or type name prefix (e.g. 'org.eclipse') is a valid entry. An import is always added to the most specific group." While this correctly describes the behavior of Organize Imports when the user has defined a "match all" import group, it does not accurately describe the behavior when the user has not defined a match-all import group. What happens is that if there is no match-all import group and, for a given import, none of the configured import groups is a prefix (of whole dot-separated name segments), then Organize Imports places the import beside the configured import group that is lexicographically closest to the import. One test case in particular (ImportRewriteTest.testAddImportsNoEmptyLines) illustrates this: given the import order { "java.util", "java.new", "p" }, the test asserts that the new import "java.net.Socket" will be placed between "java.util.Set" and "p.A". This seems plainly misleading to me. It's not at all clear to me that "java.new" is "the most specific group" into which to sort "java.net.Socket". It's not a prefix match, and "java.net" cannot in any way be said to be contained within "java.new". I think that this behavior can only mislead users, and should either be a) changed, or b) much more precisely documented. My suggestion would be to change the behavior of Organize Imports so that imports not matching any import group by complete prefix of name segments always be moved to one location, and not placed among or between defined import groups. In effect, my suggestion is that Organize Imports always assume the existence of a "match-all" (or default) import group in the import order, even if the user has not explicitly included a "*" entry on the Organize Imports configuration page. Perhaps the default sort position for non-prefix-matched imports would be at the end (after all defined import groups) in the absence of an explicit "*" entry. Note: I am currently rewriting ImportRewriteAnalyzer to fix bugs related to static on-demand imports and inner-type imports, so it would be helpful to have feedback and thoughts on this issue.
Move to UI for comment.
Since filing this bug, I have determined that the current behavior is broken in more ways (and more obviously) than I had previously realized. I have filed bug 430303 treating this behavior as clearly broken, rather than as merely undocumented, and I am closing this bug. *** This bug has been marked as a duplicate of bug 430303 ***