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

以下内容的测试条件是你的机器上,设置了path命令PATH= D:/JDK1.4/BIN;D:/JDK1.4/LIB;,可以正常执行javajavac命令,不用设置classpath路径的情况下。

    从一个简单的例子谈谈packageimport机制

基本原则:为什么需要将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 hello

Exception 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:12

3)

        at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)

        at java.net.URLClassLoader.access$100(URLClassLoader.java:55)

        at java.net.URLClassLoader$1.run(URLClassLoader.java:194)

        at java.security.AccessController.doPrivileged(Native Method)

        at java.net.URLClassLoader.findClass(URLClassLoader.java:187)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:289)

        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:235)

        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)

 

 

D:/my/xdj>

 

 

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.javab.java文件,其内容如下。

a.java文件内容:

import a.b.c.*;

public class a

{

   public static void main(String[] args)

     {

       b b1=new b();

       b1.print();

       }

 

 

}

 

 

 

 

 

 

a.java文件内容:

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 exist

import a.b.c.*;

^

a.java:6: cannot access b

bad class file: ./b.java

file does not contain class b

Please remove or make sure it appears in the correct subdirectory of the classpa

th.

       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 exist

import a.b.c.*;

^

a.java:6: cannot resolve symbol

symbol  : class b

location: class a

       b b1=new b();

       ^

a.java:6: cannot resolve symbol

symbol  : class b

location: class a

       b b1=new b();

                ^

3 errors

 

 

D:/my/xdj>java a

Exception in thread "main" java.lang.NoClassDefFoundError: a/b/c/b

        at 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>

 

 

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

 

 

深入分析packageimport机制部分

不管你有没有使用import指令,存在目前目录下的类都会被编译器优先采用,只要它不属于任何package。这是因为编译器总是先假设您所输入的类名就是该类的全名(不属于任何package),然后-classpath所指定的路径中搜索属于该类的.java文件或.class文件,在这里可以知道default package的角色非常特殊。

必须明确告诉编译器我们用到哪个package下的类,导入时或在包名称.类名称中进行引用。导入某个包时,一定要进行-classpath路径指定某个包的位置。你如果指定了多个路径话,如果在一个路径下已经找到了该包话,就优先引用该包的类。

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

   当编译器将类路径引用表建立好之后,接着编译器要确定它可以利用类引用表里的数据作为相对起始路径,找到所有用到的package

   编译器还要完成一张名为“类引用表”与“相对类引用表”的数据结构。

   整个编译程序中packageimport机制相关的部分流程如下:

 

 

开始,

 

 

建立类路径引用表与类引用表;

    如果建立成功:则类名称解析程序:

如果已存在该类的类文件,继续其它的编译工作

如果该类的文件不存在,寻找该类的源代码文件:

                         如果找到,则编译该

                          类的源代码,继续

                           其它的编译工作

                           此时,也可返回到

开始,make机制,

递归式编译。

                         如果找不到,编译

结束,发出警告

信息

    如果建立失败:编译结束,发出警告信息2)。

 

 

 

 

JAVA动态链接本质研究

不管你在同一个源代码(.java)中使用了几个类声明,它们都会一一编译成.class文件,即使是内部类、匿名类都是一样。在java中,对于每一个类所构成的类文件,都可将它视为动态链接库。

在类文件中,所有对于特写类的操作都被转换成类的全名。Import除了用来指引编译器解析出正确的类名称之外,没有其它功能。

在运行时期,仍然用到一个与编译器相同的程序,就是类路径引用表的建立,而利用动态链接载入类文件的机制流程如下:

开始,

建立类路径引用表,

根据类文件内部的信息,与类路径引用表的数据合成类文件的绝对路径。

    如果找到类文件,检查该类的类文件内部信息,是否符合相对路径信息:

                                                  如果符合,载入该类。

                                                  如果不符合,执行错误,发出

                                                     Exception信息。

    如果找不到类文件,则执行错误,发出Exception信息。

 

 

最后,需要说明的是,在java中提供许多的类包,java语言中将完成与计算机底层相关的输入输出、常用的数据类型转换等功能的函数封装在包中。如果你的程序提示找不到这样基础包的话,你就可以用参数-classpath或环境变量classpath进行指定位置来解决此类问题!

后面写的有点乱呀!不知道你能否理解呀!不过相信你看完我对packageimport的讨论后,应该会有所收获的。如果你还有任何关于packageimport的疑问的话,可以和我一起讨论和交流呀!我的邮箱是:xiaodajin@sina.com

packageimport

06-26

package 名称就像是我们的姓,而 class 名称就像是我们的名字。package 名称有很多 . 的,就好像是复姓。比如说 java.lang.String,就是复姓 java.lang,名字为 String 的类别;java.io.InputStream 则是复姓 rn  java.io,名字为 InputStream 的类别。 rnrn  Java 会使用 package 这种机制的原因也非常明显,就像我们取姓名一样,光是一间学校的同一届同学中,就有可能会出现不少同名的同学,如果不取姓的话,那学校在处理学生数据,或是同学彼此之间的称呼,就会发生很大的困扰。相同的,全世界的 Java 类别数量,恐怕比台湾人口还多,而且还不断的在成长当中,如果类别不使用套件名称,那在用到相同名称的不同类别时,就会产生极大的困扰。幸运的是,Java 的套件名称我们可以自己取,不像人的姓没有太大的选择 ( 所以有很多同名同姓的 ),如果依照 Sun 的规范来取套件名称,那理论上不同人所取的套件名称不会相同 ( 请参阅 "命名惯例"的相关文章 ),也就不会发生名称冲突的情况。 rnrn  可是问题来了,因为很多套件的名称非常的长,在写程序时,会多打好多字,花费不少时间,比如说: rnrn   java.io.InputStream is = java.lang.System.in; rn   java.io.InputStreamReader isr= new java.io.InputStreamReader(is); rn   java.io.BufferedReader br = new java.io.BufferedReader(isr); rnrn  实在是不美观又麻烦。于是,Sun 想了一个办法,就是 import。 rnrn  这个 import 就是在程序一开头的时候,先说明程序中会用到那些类别的 rn  简称,也就是只称呼名字,不称呼他的姓。首先,在档案开头写: rnrn   import java.lang.System; rn   import java.io.InputStream; rn   import java.io.InputStreamReader; rn   import java.io.BufferedReader; rnrn  这几行说明了这四个姓名的类别,在程序中只用他的名字来称呼,所以当程序中提到 System 就是指 java.lang.System,而 InputStream 就是指 java.io.InputStream,依此类推。于是原来的程序就变成: rnrn   InputStream = System.in; rn   InputStreamReader isr = new InputStreamReader(is); rn   BufferedReader br = new BufferedReader(isr); rnrn  这样看起来是不是清爽多了呢?如果这些类别用的次数很多,那就更能体会到import 的好处了。可是这样还是不够,因为懒是人的天性,还是会有人觉得打太多 import 了也很浪费时间,于是 Sun 又提供了一个方法: rnrn   import java.lang.*; rn   import java.io.*; rnrn  意思就是,等一下程序中提到的没有姓名的类别,不是姓 java.lang,就是姓java.io,如果这两个里面有同样名字的类别,而不幸的你又只用名字称呼这个类别,那编译器仍然会跟你抱怨,因为它还是不知道你说的这个类别指那一 rn  个姓的类别。那可不可以再懒一点呢,只写: rnrn   import java.*; rnrn  历史告诉我们,人可以懒,但不能太懒,这样是不行的。因为那些类别是姓 java.io 而不是姓 java。就像姓『诸葛』的人应该不会喜欢你称他为『诸』先生吧。 rnrn  为甚么我一开始说 import 跟 #include 不同呢?因为 import 的功能到此为止,它不像 #include 一样,会将档案内容载入进来。import 只是请编译器帮你打字,让编译器把没有姓的类别加上姓,并不会把别的文件的程式码写进来。如果你想练习打字,可以不要使用 import,只要在用到类别的时候,用它的全部姓名来称呼它就行了(就像例子一开始那样),跟使用 import 完全没有甚么两样。 rnrn  另外,虽然人不可以太懒,但是 Sun 还是帮我们多偷了一点懒。因为java.lang 这个套件实在是太常太常太常用到了,几乎没有程序不用它的,所以不管你有没有写 import java.lang;,编译器都会自动帮你补上,也就是说编译器只要看到没有姓的类别,它就会自动去 java.lang 里面找找看,看这个类别是不是属于这个套件的。所以我们就不用特别去 rn  import java.lang 了。 rn 感觉介绍的不错,分享给大家

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试