If a member in one package shares its name with a member in another package and both packages are imported, you must refer to each member by its qualified name. For example, the graphics package defined a class named Rectangle. The java.awt package also contains a Rectangle class. If both graphics and java.awt have been imported, the following is ambiguous.
In such a situation, you have to use the member's fully qualified name to indicate exactly which Rectangle class you want. For example,
If there is a such circumstance then it doesn't make any sense to import them when ultimately we have to use fully qualified name.
java.io.FileFilter and javax.swing.filechooser.FileFilter also can cause conflicts, especially since both share approximately the same purpose. I'm still annoyed that javax.swing.filechooser.FileFilter does not implement java.io.FileFilter because it already has its sole method.
Rob Spoor wrote:I'm still annoyed that javax.swing.filechooser.FileFilter does not implement java.io.FileFilter because it already has its sole method.
This reduces the dependency across different packages.
But you can derive a class from it having only the constructors and the "implements" clause.