从一个简单的例子谈谈package与import机制

转,原文： http://annie09.iteye.com/blog/469997

http://blog.csdn.net/gdsy/article/details/398072

这两篇我也不知道到底那篇是原创。

--------------------------------------------------------------------------------------------------

很基本的东西啦，可问题是从我借来的书上到download的电子书上都是把这部分一带而过，看的我稀里糊涂，导致我在写自己的包用的时候总是出一堆的错误还不明所以，于是上网查了查把别人的东西“偷”了出来供像我一样的初学者们分享：

 

从一个简单的例子谈谈package与import机制

基本原则：为什么需要将Java文件和类文件切实安置到其所归属之Package所对应的相对路径下。 为什么要这样做呢？如果你在程序中，用到打包命令package，并且直接编译和执行该程序。例如：以下面程序为例：

package a.b.c;

public class hello{
         public static void main(String args[]) {
                 System.out.println("Hello the world!");
         }
}

  

 

此程序可以编译通过，但是执行时，却提示以下错误！

D:\my\xdj>javac hello.java 
D:\my\xdj>java helloException in thread "main" java.lang.NoClassDefFoundError: hello (wrong name: a/b/c/hello) 
at java.lang.ClassLoader.defineClass0(Native Method)at java.lang.ClassLoader.defineClass(ClassLoader.java:537)at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) 
at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) 
at java.net.URLClassLoader.access$100(URLClassLoader.java:55) 
atjava.net.URLClassLoader$1.run(URLClassLoader.java:194) 
atjava.security.AccessController.doPrivileged(Native Method) 
atjava.net.URLClassLoader.findClass(URLClassLoader.java:187) 
atjava.lang.ClassLoader.loadClass(ClassLoader.java:289) 
atsun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) 
atjava.lang.ClassLoader.loadClass(ClassLoader.java:235) 
atjava.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) 

 
如果在 D:\my\xdj> 目录下建立一个\a\b\c子目录把hello.java放在它下面，用以下命令进行编译和执行时，就可正常通过！ 

D:\my\xdj>javac d:\my\xdj\a\b\c\hello.java 
D:\my\xdj>java a.b.c.hello 
Hello the world! 
D:\my\xdj>

 

 
再看下面另外一种情况，先让我们在xdj目录下建立两个文件a.java和b.java文件，其内容如下。

import a.b.c.*;

public class a{
        public static void main(String[] args){
                  b b1=new b();
                  b1.print();
        }
}

 

package a.b.c;

public class b{
       public void print() {
                System.out.println("我是被调用子类的程序输出呀！");
       }
}

 

 

直接编译a.java文件时，会提示以下错误！

 

 

D:\my\xdj>javac a.java 
a.java:1: package a.b.c does not existimport 
a.b.c.*;^a.java:6: cannot access bbad class file: .\b.javafile does not contain class 
bPlease remove or make sure it appears in the correct subdirectory of the classpath. b 
b1=new b(); ^2 errors 
D:\my\xdj> 

 

接下来，我们把b.java移到xdj\a\b\c\下，并把\xdj目录下的b.java删除掉呀！重新执行编译指令，这次肯定可以编译成功！你可以发现b.java也同时被编译过了，这就是所谓的make编译方式。

D:\my\xdj>javac a.java 
D:\my\xdj> 

 

提示1：如果你在\xdj目录下仍保留一个b.java文件的话，执行对主程序的编译命令时仍会报错！你自己可以试试呀！

提示2：如果你删除\xdj\a\b\c\b.java文件的话，保留b.class文件，执行对主程序的编译命令时是可以通过，此地可以不需要子程序的源代码。 

提出一个问题：如果把目录\a\b\c全部剪切到其它目录，如D盘根目录下，在\xdj目录如果执行编译和执行命令呢？ 很明显，会报以下错误！当然了，前提条件是你没有设置classpath路径，其实只要没把类搜索路径设置到我这个位置就会出错的！你试试吧！

D:\my\xdj>javac a.java 
a.java:1: package a.b.c does not existimport a.b.c.*;^a.java:6: cannot resolve 
symbolsymbol : class blocation: class a b b1=new b(); ^a.java:6: cannot resolve 
symbolsymbol : class blocation: class a b b1=new b();^3 errors D:\my\xdj>java 
aException in thread "main" java.lang.NoClassDefFoundError: a/b/c/bat a.main(a.java:6) 
D:\my\xdj>

 

解决的办法可以用以下命令即可正常编译和执行： 

D:\my\xdj>javac -classpath d：\ a.java 
D:\my\xdj>java -classpath d：\；a 
我是被调用子类的程序输出呀！ 
D:\my\xdj>

  

提示3：-classpath参数，缺省是以当前目录为根基目录的，即不带-classpath参数的情况下。   

提示4：使用java.exe还是javac.exe，最好明确指定-classpath选项，可设置环境变量CLASSPATH即可，同时设置了-classpath参数和环境变量classpath时，会以-classpath参数为主的。如果在它们所指定的路径或JAR文件中存有package名称和类名称相同的类，会引起混淆的！ 如果你在D盘的根目录生成一个打包文件a.zip，其内容目录a\b\c\下的所有文件的话，你也可以用下面命令进行编译和执行。

D:\my\xdj>javac -classpath d:\a.zip a.java 
D:\my\xdj>java -classpath d:\a.zip;. a 
我是被调用子类的程序输出呀！ 
D:\my\xdj> 

 

以上讨论就暂告一段落吧！如果你还想进一步了解package与import机制话，哪你可以继续往下看下去的。

深入分析package与import机制部分 

不管你有没有使用import指令，存在目前目录下的类都会被编译器优先采用，只要它不属于任何package。这是因为编译器总是先假设您所输入的类名就是该类的全名（不属于任何package），然后-classpath所指定的路径中搜索属于该类的.java文件或.class文件，在这里可以知道default package的角色非常特殊。必须明确告诉编译器我们用到哪个package下的类，导入时或在包名称.类名称中进行引用。导入某个包时，一定要进行-classpath路径指定某个包的位置。你如果指定了多个路径话，如果在一个路径下已经找到了该包话，就优先引用该包的类。

 

当java编译器开始编译某个类的源代码时，首先它会做一件事情，这就是建立“类路径引用表”，它是根据参数-classpath或classpath环境变量来建立的。如果没有指定选项-classpath或环境变量CLASSPATH时，缺省情况下类路径引用表只有一笔记录，即当前的目录(“.”)。环境变量CLASSPATH的内容会被选项-classpath所覆盖，没有累加效果。

  

当编译器将类路径引用表建立好之后，接着编译器要确定它可以利用类引用表里的数据作为相对起始路径，找到所有用到的package。   编译器还要完成一张名为“类引用表”与“相对类引用表”的数据结构。   整个编译程序中package与import机制相关的部分流程如下：

 

开始， 建立类路径引用表与类引用表；如果建立成功：则类名称解析程序：如果已存在该类的类文件，继续其它的编译工作。如果该类的文件不存在，寻找该类的源代码文件： 如果找到，则编译该 类的源代码，继续   其它的编译工作。   此时，也可返回到开始，make机制，递归式编译。 如果找不到，编译 结束，发出警告 信息。如果建立失败：编译结束，发出警告信息（2）。 JAVA动态链接本质研究 不管你在同一个源代码（.java）中使用了几个类声明，它们都会一一编译成.class文件，即使是内部类、匿名类都是一样。在java中，对于每一个类所构成的类文件，都可将它视为动态链接库。在类文件中，所有对于特写类的操作都被转换成类的全名。

 

Import除了用来指引编译器解析出正确的类名称之外，没有其它功能。在运行时期，仍然用到一个与编译器相同的程序，就是类路径引用表的建立，而利用动态链接载入类文件的机制流程如下：开始，建立类路径引用表，根据类文件内部的信息，与类路径引用表的数据合成类文件的绝对路径。如果找到类文件，检查该类的类文件内部信息，是否符合相对路径信息： 如果符合，载入该类。 如果不符合，执行错误，发出 Exception信息。如果找不到类文件，则执行错误，发出Exception信息。 最后，需要说明的是，在java中提供许多的类包，java语言中将完成与计算机底层相关的输入输出、常用的数据类型转换等功能的函数封装在包中。如果你的程序提示找不到这样基础包的话，你就可以用参数-classpath或环境变量classpath进行指定位置来解决此类问题！
　

有些人写了一阵子 Java，可是对于 Java 的 package 跟 import 还是不太了解。很多人以为原始码 .java 文件中的 import 会让编译器把所 import 的程序通通写到编译好的 .class 档案中，或是认为 import 跟 C/C++ 的 #include 相似，实际上，这是错误的观念。 
　　

让我们先了解一下，Java 的 package 到底有何用处。 
　　

其实，package 名称就像是我们的姓，而 class 名称就像是我们的名字。package 名称有很多 . 的，就好像是复姓。比如说 java.lang.String，就是复姓 java.lang，名字为 String 的类别；java.io.InputStream 则是复姓 j

ava.io，名字为 InputStream 的类别。 
　　

Java 会使用 package 这种机制的原因也非常明显，就像我们取姓名一样，光是一间学校的同一届同学中，就有可能会出现不少同名的同学，如果不取姓的话，那学校在处理学生数据，或是同学彼此之间的称呼，就会发生很大的困扰。相同的，全世界的 Java 类别数量，恐怕比台湾人口还多，而且还不断的在成长当中，如果类别不使用套件名称，那在用到相同名称的不同类别时，就会产生极大的困扰。幸运的是，Java 的套件名称我们可以自己取，不像人的姓没有太大的选择 ( 所以有很多同名同姓的 )，如果依照 Sun 的规范来取套件名称，那理论上不同人所取的套件名称不会相同 ( 请参阅 "命名惯例"的相关文章 )，也就不会发生名称冲突的情况。 
　　

可是问题来了，因为很多套件的名称非常的长，在写程序时，会多打好多字，花费不少时间，比如说： 
　　 java.io.InputStream is = java.lang.System.in; 
　　 java.io.InputStreamReader isr= new java.io.InputStreamReader(is); 
　　 java.io.BufferedReader br = new java.io.BufferedReader(isr); 
　　

实在是不美观又麻烦。于是，Sun 想了一个办法，就是 import。 
这个 import 就是在程序一开头的时候，先说明程序中会用到那些类别的 
简称，也就是只称呼名字，不称呼他的姓。首先，在档案开头写： 
　　 import java.lang.System; 
　　 import java.io.InputStream; 
　　 import java.io.InputStreamReader; 
　　 import java.io.BufferedReader; 
　　

这几行说明了这四个姓名的类别，在程序中只用他的名字来称呼，所以当程序中提到 System 就是指 java.lang.System，而 InputStream 就是指 java.io.InputStream，依此类推。于是原来的程序就变成： 
　　 InputStream = System.in; 
　　 InputStreamReader isr = new InputStreamReader(is); 
　　 BufferedReader br = new BufferedReader(isr); 
　　

这样看起来是不是清爽多了呢？如果这些类别用的次数很多，那就更能体会到import 的好处了。可是这样还是不够，因为懒是人的天性，还是会有人觉得打太多 import 了也很浪费时间，于是 Sun 又提供了一个方法： 
　　 import java.lang.*; 
　　 import java.io.*; 
　　

意思就是，等一下程序中提到的没有姓名的类别，不是姓 java.lang，就是姓java.io，如果这两个里面有同样名字的类别，而不幸的你又只用名字称呼这个类别，那编译器仍然会跟你抱怨，因为它还是不知道你说的这个类别指那一个姓的类别。那可不可以再懒一点呢，只写： 
　　 import java.*; 
　　

历史告诉我们，人可以懒，但不能太懒，这样是不行的。因为那些类别是姓 java.io 而不是姓 java。就像姓『诸葛』的人应该不会喜欢你称他为『诸』先生吧。 
　　

为甚么我一开始说 import 跟 #include 不同呢？因为 import 的功能到此为止，它不像 #include 一样，会将档案内容载入进来。import 只是请编译器帮你打字，让编译器把没有姓的类别加上姓，并不会把别的文件的程式码写进来。如果你想练习打字，可以不要使用 import，只要在用到类别的时候，用它的全部姓名来称呼它就行了(就像例子一开始那样)，跟使用 import 完全没有甚么两样。 
　　

另外，虽然人不可以太懒，但是 Sun 还是帮我们多偷了一点懒。因为java.lang 这个套件实在是太常太常太常用到了，几乎没有程序不用它的，所以不管你有没有写 import java.lang;，编译器都会自动帮你补上，也就是说编译器只要看到没有姓的类别，它就会自动去 java.lang 里面找找看，看这个类别是不是属于这个套件的。所以我们就不用特别去 
　　import java.lang 了。