Community
Participate
Working Groups
Build Identifier: 20100617-1415 The Number of Imports needed for .* is ignored when organizing imports via Ctrl+Shift+O. The Number of Imports is configured to 2. My class has 3 imports of the same package, which could be replaced by .*. When the imports are organized, nothing is happenening. If I replace the 3 imports manually with .* and then organize the imports via Ctrl+Shift+O again, .* is replaced with the 3 imports again. Reproducible: Always Steps to Reproduce: 1. Configure Number of Imports to 2 (Preferences/Java/Code Style/Organize Imports/Number of Imports needed for .*) 2. Create a Class with more than 2 imports of the same package. 3. Organize the imports via Ctrl+Shift+P. 4. Nothing is happening, although the imports should be replaced with .*.
I couldn't reproduce this using the following case and preferences set as per comment 0: import java.util.ArrayList; import java.util.Arrays; import java.util.LinkedList; public class Test { ArrayList a; Arrays b; LinkedList l; } CTRL-SHIFT-O leads to import java.util.* Can you please provide a testcase?
(In reply to comment #0) > Build Identifier: 20100617-1415 > 3. Organize the imports via Ctrl+Shift+P. > 4. Nothing is happening, although the imports should be replaced with .*. I don't see the bug either. And I am assuming "Ctrl+Shift+P" is not a typo here.
> Can you please provide a testcase? I am sorry, my bug description was not good enough. Here is a testcase with two classes in two different packages to reproduce: package MyPackage; public class Constants { public static final class SomeConstants { public static final String CONSTANT_A = "A"; } public static final class OtherConstants { public static final String CONSTANT_B = "B"; } } package OtherPackage; import MyPackage.Constants.OtherConstants; import MyPackage.Constants.SomeConstants; public class Test { String str = SomeConstants.CONSTANT_A + OtherConstants.CONSTANT_B; } Ctrl+Shift+O does not lead to the import "MyPackage.Constants.*" as it did with Eclipse 3.5.
I'll take a look.
The problem comes from the fact that the import groups are created with the package name as the key. In this case, we should create an import group using a toplevel name. I don't know yet how to fix it without breaking other cases. Markus, is it intended to work for top level type names? In 3.5, it was working because it never tried to find the package name for the import group key. It was just using the type name - the last segment.
The current code was added in 3.6 to be able to handle java.util.Map.Entry and adds this kind of import inside the same group as java.util.Map. This is why it retrieves the package as the qualifier for an import and not the type name. The only way I see to fix this would be to add some logic to replace some imports with a '*' import within the group itself. Markus, any thoughts on this ?
We have the same problem if the import group is "MyPackage.Constants". And if you add Constants c; , then you get an "import MyPackage.*;", although that import only stands for the single type MyPackage.Constants. I guess the problem is that you use the same data structure PackageEntry for 2 different purposes: 1) grouping of imports from the same package 2) combining multiple imports to an on-demand import Before bug 194358, these used to be the same, but now a PackageEntry no longer contains only entries with the same qualifier. I guess you'll have to separate these concerns, but I don't know that code well enough to be able to just pull out a clever trick out of my sleeve.
Any news on this?
> Any news on this? You would have heard it here. To speed things up, you can provide a patch that fixes the issue. Code is in ImportRewriteAnalyzer (org.eclipse.jdt.core) and tests are in ImportRewriteTest (org.eclipse.jdt.core.tests.model). If you want to work on this, please tell it here, so that we don't waste resources working on the same problem in parallel.
I have nearly finished a fix for this.
Fixed via bug 430303.
Verified for 4.5 M6 with build I20150316-2000.
