USING IMPORT DECLARATIONSIf you've done any amount of Java programming, you've likely used import declarations, of the form: import java.util.*;or:
import java.util.ArrayList;These are quite simple in a way, but there are a couple of interesting issues to mention concerning the use of these declarations. The first point is that an import declaration makes a type or set of types available, but doesn't do any textual inclusion of files. By contrast, the C #include directive actually substitutes text into the including file. So that:
#include <stdio.h>actually results in a header file stdio.h being inserted into the compilation unit. In Java programming, a corresponding declaration:
import java.util.ArrayList;simply says that the class type ArrayList can be used in the program without full qualification (that is, ArrayList instead of java.util.ArrayList).
There's an implicit import declaration: import java.lang.*;assumed at the beginning of a Java compilation unit, just after any package statement in the unit. A wildcard like "*" says "make available all public types from the package", in this case, all types in the package java.lang. Wildcards are never used to import subpackages, so an import like:
import java.lang.*;doesn't give you access to the classes in java.lang.reflect, a subpackage of java.lang. You need to say:
import java.lang.reflect.*;to access those classes.
What about ambiguities? What if you import two types with the same name from different packages? import P1.A;
import P2.A;This is invalid usage. However, what if you say instead:
import P1.*;
import P2.*;and both packages P1 and P2 contain an A type? Well, if you don't actually use the A in your program, then it's okay. But if you say:
A a = new A();you'll get an ambiguity error. In other words, you get an error if (a) you use a type-import-on-demand declaration (that is, an import declaration using a wildcard), (b) two different packages have types with the same name, (c) you use that type. There is no rule that says "the first one wins".
There are a couple of different styles you can use with imports. Suppose you need to use ArrayList and Vector from java.util. You can say: import java.util.*;or:
import java.util.ArrayList;
import java.util.Vector;These are both "right". The first is terse; you don't have to enumerate all the types you're using. The second makes clear what types you're using in your program, at the expense of some verboseness. The second approach also has a subtle advantage in that it forces a type to be found in a particular package. Here's an example. Suppose you want to use a type A, and you say:
import P1.*;
import P2.*;And you believe that A is found in P1, when it's actually not in P1 but in P2. Explicitly enumerating the types you're using gets around this problem. If you think A is in P1, and you say:
import P1.A;and it's not actually there, you'll get a compile error.
Is there any efficiency issue between these two styles? Possibly, but since import declarations don't actually import anything into your program, any difference is very small. Remember that there's an implicit import java.lang.* at the top of your compilation units, and java.lang in JDKTM 1.2.2 contains 75 classes and interfaces. An experiment using a contrived example, one with thousands of class name uses that must be looked up, showed a negligible change in compilation speed. So compilation performance should probably not be considered a factor when choosing one format over another. There's one final angle of interest on import declarations. Suppose you use an inner class: package P; public class A {
public static class B {}
}If you want to access A from another compilation unit, you say:
import P.*;or:
import P.A;But if you'd like to access B without qualification, you need to say:
import P.A.*;or:
import P.A.B;The first of these makes available types within the class A found in package P. The second makes available just the type B found in class A in package P.
import java.util.ArrayList;These are quite simple in a way, but there are a couple of interesting issues to mention concerning the use of these declarations. The first point is that an import declaration makes a type or set of types available, but doesn't do any textual inclusion of files. By contrast, the C #include directive actually substitutes text into the including file. So that:
#include <stdio.h>actually results in a header file stdio.h being inserted into the compilation unit. In Java programming, a corresponding declaration:
import java.util.ArrayList;simply says that the class type ArrayList can be used in the program without full qualification (that is, ArrayList instead of java.util.ArrayList).
There's an implicit import declaration: import java.lang.*;assumed at the beginning of a Java compilation unit, just after any package statement in the unit. A wildcard like "*" says "make available all public types from the package", in this case, all types in the package java.lang. Wildcards are never used to import subpackages, so an import like:
import java.lang.*;doesn't give you access to the classes in java.lang.reflect, a subpackage of java.lang. You need to say:
import java.lang.reflect.*;to access those classes.
What about ambiguities? What if you import two types with the same name from different packages? import P1.A;
import P2.A;This is invalid usage. However, what if you say instead:
import P1.*;
import P2.*;and both packages P1 and P2 contain an A type? Well, if you don't actually use the A in your program, then it's okay. But if you say:
A a = new A();you'll get an ambiguity error. In other words, you get an error if (a) you use a type-import-on-demand declaration (that is, an import declaration using a wildcard), (b) two different packages have types with the same name, (c) you use that type. There is no rule that says "the first one wins".
There are a couple of different styles you can use with imports. Suppose you need to use ArrayList and Vector from java.util. You can say: import java.util.*;or:
import java.util.ArrayList;
import java.util.Vector;These are both "right". The first is terse; you don't have to enumerate all the types you're using. The second makes clear what types you're using in your program, at the expense of some verboseness. The second approach also has a subtle advantage in that it forces a type to be found in a particular package. Here's an example. Suppose you want to use a type A, and you say:
import P1.*;
import P2.*;And you believe that A is found in P1, when it's actually not in P1 but in P2. Explicitly enumerating the types you're using gets around this problem. If you think A is in P1, and you say:
import P1.A;and it's not actually there, you'll get a compile error.
Is there any efficiency issue between these two styles? Possibly, but since import declarations don't actually import anything into your program, any difference is very small. Remember that there's an implicit import java.lang.* at the top of your compilation units, and java.lang in JDKTM 1.2.2 contains 75 classes and interfaces. An experiment using a contrived example, one with thousands of class name uses that must be looked up, showed a negligible change in compilation speed. So compilation performance should probably not be considered a factor when choosing one format over another. There's one final angle of interest on import declarations. Suppose you use an inner class: package P; public class A {
public static class B {}
}If you want to access A from another compilation unit, you say:
import P.*;or:
import P.A;But if you'd like to access B without qualification, you need to say:
import P.A.*;or:
import P.A.B;The first of these makes available types within the class A found in package P. The second makes available just the type B found in class A in package P.
import xxxx.xxx.……;
public class extends someclass implements someinterface{
…………
}
就这么用
就是你在一开始一个包也不import,但在程序里写全名,
一样可以.
c要是不include
就不可以了吧.
就是为了区别别的包的.
所以才用域名倒过来.随便找本书上都有的.read book偶E文不好,你就对付着看吧,反正都是CHINAREN.