No i think i haven't made my question clear . sorry about that .
when i have a scenario as in my two programs in my previous post, I have imported class 'Arrays' from another package java.util as well as created a user defined class 'Arrays' in the same program . So, under such a scenario when i use
import java.util.Arrays.*; i get no error in the program .
but when i use import java.util.Arrays; i get an error .
it is under such a situation when you have same class names, that i want to know the difference between the 2 imports .
i have once again pasted the 2 programs below with the 2 different import statements in each .
NO ERROR :
CAN SOMEBODY EXPLAIN .
Enthuware Software Support
posted 3 years ago
Sorry, I realized now that you are not using static import.
The statement import java.util.Arrays.*; imports the class * from package java.util.Arrays.
So it is ok to define Arrays class in your code. There is only one Arrays class available in scrap in this case.
The statement import java.util.Arrays; imports the class Arrays from package java.util. So now you have two Arrays classes available in scrap code. Compiler realizes that there is ambiguity in the name Arrays so it complains.
shambhavi sivan wrote:java.util.Arrays cannot be a package because it clashes with the Arrays class in the java.util pakage already provided by java.
This is *not* true. Remember that a classpath can have multiple directories. So, yes, with the default rt.jar, it will clash, and hence, can't be a package... but you can have a separate directory in the classpath (and also, separate jar files)... ie. it is possible to have that package and not clash.
shambhavi sivan wrote:
what happens when a wildcard is specified after a class name in the import statement ?
As already mentioned, it loads all the classes/interfaces from the package... in this example, the "package1.sub_package1.classA" package.
And also, even if it wasn't possible to not have a clash, how does the first point lead to the second point (your question)? According to the specification, in your example, the package is named "package1.sub_package1.classA". There is nothing in the specification that states, that if there is some class with a conflicting name, then it is not a package.
Oops... This is embarrassing. I completely forgotten about nested classes in this context. Yes, it is possible for the import to succeed, even if only ClassA exists (meaning no package named ClassA). In this case, the compiler will be trying to import the nested classes of the ClassA class.