Eclipse把Java构建路径的信息放在“.classpath”文件中,此文件位于项目文件夹根目录。直接修改“.classpath”内容也可以设置构建路径,但必须在修改后对项目进行刷新。
classpath ——工作区内的主目录
一、java虚拟机启动过程:
java虚拟机是由java luncher初始化的,也就是java(或java.exe)
这个程序来做的. 虚拟机按以下顺序搜索并装载所有需要的类:
1, 引导类: 组成java平台的类, 包含rt.jar和i18n.jar中的类.
2, 扩展类: 使用java扩展机制的类,都是位于扩展目录($JAVA_HOME/jre/lib/ext)中的.jar档案包.
3, 用户类: 开发者定义的类或者没有使用 java 扩展机制的第三方产品. 你必须在命令行中使用 -classpath 选项或者使用 CLASSPATH 环境变量来确定这些类的位置.
在执行Java程序的时候,会自动加载程序用中需要的在rt.jar和其他java_home\jre\lib中包含的.jar文件中包含的Java基础类库和一些扩展类库。这些都是JVM自动处理的,对用户来说是透明的。
如果Java程序中使用到了一些应用级别的类(如第三方的类),可以在javac和java中的-classpath选项中指定它们的搜索路径,或者是自 己写ClassLoader加载,另外也可以设置ClassPath环境变量,在里面指定那些应用级别的类的搜索路径。
设置ClassPath环境变量不是必须的,只是为了方便使用,设置了ClassPath,JDK就会按ClassPath制定的路径去搜索需要的应用级别的类,而不必每一次都使用-classpath选项或自己写ClassLoader。
还有需要注意的就是:如果相关的类就在当前工作目录下的话,上面3种方法都可以不要,因为JDK系统会首先搜索会在当前的工作目录中搜索程序相关的类。
二、Classpath(类路径)基础
Java虚拟机(JVM)借助类装载器装入应用程序使用的类,具体装入哪些类根据当时的需要决定。CLASSPATH环境变量告诉类装载器到哪里去寻找第三方提供的类和用户定义的类。另外,你也可以使用JVM命令行参数-classpath分别为应用程序指定类路径,在-classpath中指定的类路径覆盖CLASSPATH环境变量中指定的值。
类路径中的内容可以是:文件的目录(包含不在包里面的类),包的根目录(包含已打包的类),包含类的档案文件(比如.zip文件或者.jar文件)。在Unix家族的系统上,类路径的各个项目由冒号分隔,在MS Windows系统上,它们由分号分隔。
类装载器以委托层次的形式组织,每一个类装载器有一个父类装载器。当一个类装载器被要求装载某个类时,它在尝试自己寻找类之前会把请求先委托给它的父类装载器。系统类装载器,即由安装在系统上的JDK或JRE提供的默认类装载器,通过CLASSPATH环境变量或者-classpath这个JVM命令行参数装入第三方提供的类或者用户定义的类。系统类装载器委托扩展类装载器装入使用Java Extension机制的类。扩展类装载器委托自举类装载器(bootstrap class loader)装入核心JDK类。
你可以自己开发特殊的类装载器,定制JVM如何动态地装入类。例如,大多数Servlet引擎使用定制的类装载器,动态地装入那些在classpath指定的目录内发生变化的类。
必须特别注意的是(也是令人吃惊的是),类装载器装入类的次序就是类在classpath中出现的次序。类装载器从classpath的第一项开始,依次检查每一个设定的目录和压缩文件,尝试找出待装入的类文件。当类装载器第一次找到具有指定名字的类时,它就把该类装入,classpath中所有余下的项目都被忽略。
看起来很简单,对吧?
三、可能出现的问题
不管他们是否愿意承认,初学者和富有经验的Java开发者都一样,他们都曾经在某些时候(通常是在那些最糟糕的情形下)被冗长、复杂的classpath欺骗。应用程序所依赖的第三方类和用户定义类的数量逐渐增长,classpath也逐渐成了一个堆积所有可能的目录和档案文件名的地方。此时,类装载器首先装载的究竟是哪一个类也就不再显而易见。如果classpath中包含重复的类入口,这个问题尤其突出。前面已经提到,类装载器总是装载第一个它在classpath中找到的具有合适名字的类,从实际效果看,它“隐藏”了其他具有合适名字但在classpath中优先级较低的类。
如果不小心,你很容易掉进这个classpath的陷阱。当你结束了一天漫长的工作,最后为了让应用程序使用最好、最新的类,你把一个目录加入到了classpath,但与此同时,你却忘记了:在classpath的另一个具有更高优先级的目录下,存放着该类的另一个版本!