JAVA_HOME和TOMCAT_HOME

12月13日

为什么要设置 JAVA_HOME, TOMCAT_HOME 等环境变量?

来源：http://topic.yesky.com/topic/146/579837.html

  你可能把tomcat装在c:\tomcat里，也可能把tomcat装在d:\jerrymouse里，tomcat怎么知道自己的文件都在哪儿呢?  在Windows里面程序可以到registry里查，java是跨平台的，不应该读registry，而应该利用更通用的途径，比如象 tomcat_home这样的操作系统环境变量。

为了保持独立与操作系统的特性，java程序并不能直接读到操作系统环境变量。如果不用任何诡计，java程序只能“求”你在启动程序的时候利用java的-D参数把变量告诉它。比如java -Djava_home=%java_home % start_the_servlet_engine.你一定很讨厌每次都打如-D...那些东西，所以通常这种东西都放在一个.bat文件或是 unix的.sh文件里。

实际上tomcat就是这样利用java_home的，用这个办法找到java编译器，然后调用java编译器来编译jsp和servlet程序。至于tomcat_home，可能只是.bat文件里用的。因为.bat文件里不应该写c:\tomcat\bin\ start_engine这样的话，以防你的tomcat躲在d:\jerrymouse里，所以它写成%tomcat_home%\bin\ start_engine。(我不记得具体的程序名，可能不是"start_engine"是别的什么东东，但是这个道理。

java程序怎样读-D参数给的变量? 用System.getProperty("变量名")。

如果你想读到Windows的那些环境变量(在cmd窗口里用set看到的那些)，就要用一些阴谋诡计，那样的程序通常很丑陋。

tomcat 文件夹里面没有java编译器，除非自己你装进去，但是要运行tomcat，你的电脑里一定要有java编译器，并且把路径通过java_home告诉 tomcat。如果你的电脑里java在c:\jdk1.4.0里面，java_home就应该设成c:\jdk1.4.0。

你写的那些 servlet，tomcat都要先用java编译器编译过才能运行，其实运行也是用java_home里的java虚拟机，tomcat只不过是通过 Process的get...Stream方法同servlet交互再把结果通过普通的java socket传给浏览器。

jsp由tomcat转换成servlet的java源程序，再用%java_home%\bin\javac编译。所以，jsp和servlet的最终class文件结构上没有什么不同。

java 下的Classpath 配置

和Java 类路径（classpath）打交道的过程中，开发者偶尔会遇到麻烦。这是因为，类装载器实际装入的是哪一个类有时并不显而易见，当应用程序的 classpath包含大量的类和目录时，情况尤其严重。本文将提供一个工具，它能够显示出被装入类文件的绝对路径名。 


一、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的另一个具有更高优先级的目录下，存放着该类的另一个版本！ 


三、一个简单的classpath工具 


　　优先级问题是扁平路径声明方法与生俱来固有的问题，但它不是只有Java的classpath才有的问题。要解决这个问题，你只需站到富有传奇色彩的软件巨构的肩膀上：Unix操作系统有一个which命令，在命令参数中指定一个名字，which就会显示出当这个名字作为命令执行时执行文件的路径名。实际上，which命令是分析PATH变量，然后找出命令第一次出现的位置。对于Java的类路径管理来说，这应该也是一个好工具。在它的启发之下，我着手设计了一个Java工具JWhich。这个工具要求指定一个Java类的名字，然后根据classpath的指引，找出类装载器即将装载的类所在位置的绝对路径。 


　　下面是一个JWhich的使用实例。它显示出当Java类装载器装载com.clarkware.ejb.ShoppingCartBean类时，该类第一次出现位置的绝对路径名，查找结果显示该类在某个目录下： 


> java JWhich com.clarkware.ejb.ShoppingCartBean 

Class ´com.clarkware.ejb.ShoppingCartBean´ found in 
´/home/mclark/classes/com/clarkware/ejb/ShoppingCartBean.class´ 


　　下面是第二个JWhich的使用实例。它显示出当Java类装载器装载javax.servlet.http.HttpServlet类时，该类第一次出现位置的绝对路径名，查找结果显示该类在某个档案文件中： 

> java JWhich javax.servlet.http.HttpServlet 

Class ´javax.servlet.http.HttpServlet´ found in 
´file:/home/mclark/lib/servlet.jar!/javax/servlet/http/HttpServlet.class´ 


四、JWhich的工作过程 
　　要精确地测定classpath中哪一个类先被装载，你必须深入到类装载器的思考方法。事实上，具体实现的时候并没有听起来这么复杂——你只需直接询问类装载器就可以了！ 

1: public class JWhich { 
2: 
3: /** 
4: * 根据当前的classpath设置， 
5: * 显示出包含指定类的类文件所在 
6: * 位置的绝对路径 
7: * 
8: * @param className <类的名字> 
9: */ 
10: public static void which(String className) { 
11: 
12: if (!className.startsWith("/")) { 
13: className = "/" + className; 
14: } 
15: className = className.replace(´.´, ´/´); 
16: className = className + ".class"; 
17: 
18: java.net.URL classUrl = 
19: new JWhich().getClass().getResource(className); 
20: 
21: if (classUrl != null) { 
22: System.out.println("\nClass ´" + className + 
23: "´ found in \n´" + classUrl.getFile() + "´"); 
24: } else { 
25: System.out.println("\nClass ´" + className + 
26: "´ not found in \n´" + 
27: System.getProperty("java.class.path") + "´"); 
28: } 
29: } 
30: 
31: public static void main(String args[]) { 
32: if (args.length > 0) { 
33: JWhich.which(args[0]); 
34: } else { 
35: System.err.println("Usage: java JWhich "); 
36: } 
37: } 
38: } 

　　首先，你必须稍微调整一下类的名字以便类装载器能够接受（12-16行）。在类的名字前面加上一个“/”表示要求类装载器对classpath中的类名字进行逐字精确匹配，而不是尝试隐含地加上调用类的包名字前缀。把所有“.”转换为“/”的目的是，按照类装载器的要求，把类名字格式化成一个合法的 URL资源名。 

　　接下来，程序向类装载器查询资源，这个资源的名字必须和经过适当格式化的类名字匹配（18-19行）。每一个 Class对象维护着一个对装载它的ClassLoader对象的引用，所以这里是向装载JWhich类的类装载器查询。 Class.getResource()方法实际上委托装入该类的类装载器，返回一个用于读取类文件资源的URL；或者，当指定的类名字不能在当前的 classpath中找到时，Class.getResource()方法返回null。 


最后，如果当前的classpath 中能够找到指定的类，则程序显示包含该类的类文件所在位置的绝对路径名（21-24行）。作为一种调试辅助手段，如果当前classpath中不能找到指定的类，则程序获取java.class.path系统属性并显示当前的classpath（24-28行）。 

　　很容易想象，在使用 Servlet引擎classpath的Java Servlet中，或者在使用EJB服务器classpath的EJB组件中，上面这段简单的代码是如何运作。例如，如果JWhich类是由Servlet引擎的定制类装载器装入，那么程序将用Servlet引擎的类装载器去寻找指定的类。如果 Servlet引擎的类装载器不能找到类文件，它将委托它的父类装载器。一般地，当JWhich被某个类装载器装入时，它能够找出当前类装载器以及所有其父类装载器所装入的所有类。 

　　【结束语】如果需要是所有发明之母，那么帮助我们管理Java类路径的工具可以说迟到了很长时间。 Java新闻组和邮件列表中充塞着许多有关classpath的问题，现在JWhich为我们提供了一个简单却强大的工具，帮助我们在任何环境中彻底玩转 Java类路径。