查看“JRE”的源代码



JRE为Java Runtime Envirment的简称，Java Runtime Environment（包括JavaPlug-in）是Sun的产品，包括两部分：Java Runtime Environment和JavaPlug-in Java Runtime Environment（JRE）是可以在其上运行、测试和传输应用程序的Java平台。它包括[[Java虚拟机]]、Java平台核心类和支持[[文件]]。它不包含开发工具--编译器、调试器和其它工具。JRE需要辅助[[软件]]--JavaPlug-in--以便在浏览器中运行[[applet]]。



 JavaPlug-in软件允许Java applet和JavaBeans[[组件]]在使用Sun的Java Runtime Environment（JRE）的浏览器中运行，而不是在使用缺省的Java运行环境的浏览器中运行。Java Plug-in可用于Netscape Navigator和Microsoft Internet Explorer。


[[J2RE]]是Java2 Runtime Environment，即Java运行环境，有时简称JRE。如果你只需要运行Java程序或Applet，下载并安装它即可。如果你要自行开发 Java软件，请下载[[JDK]]。在JDK中附带有JRE。注意由于Microsoft对Java的支持不完全，请不要使用IE自带的虚拟机来运行 Applet，务必安装一个JRE或JDK。



一、JRE的版本管理 


Java的解决办法是每个程序自己携带一套JRE。



 我的机器上已经被安装了好多套JRE和JDK了（JDK包括了同版本的JRE，此外还包括有编译器和其它工具），它们分别是：BEA Weblogic Server 7.0 自带一套 JDK1.3.1_02 我下载了一套最新的JDK1.4.1_02 JBuilder9自带一套JKD1.4.1_02 [[Oracle]]8.1.7自带一套JRE1.1.7 Ration Rose自带一套JDK1.3 DreamWeaver自带一套JDK1.3 


6套JRE，每套JRE都被各自安装到不同的目录，不会互相影响。当在控制台执行java.exe，[[操作系统]]寻找JRE的方式如下：



先找当前目录下有没有JRE 再找父目录下有没有JRE 接着在PATH路径中找JRE 注册表HKEY_LOCAL_MACHINESOFTWAREJavaSoftJava Runtime Environment 查看CurrentVersion的键值指向哪个JRE 


最常用的是在PATH路径中找JRE，一般情况下，自己的程序运行之前都会先在批处理文件里面临时设置PATH，把自己用的JRE放到PATH路径最前面，所以肯定会运行自己带的JRE，不会造成版本混乱。



 .Net [[Framework]]的版本管理 


.Net Framework被固定安装在C:WinntMicrosoft.NETFrameworkv版本号目录下，并且在同一台机器只能安装一套，要安装1.1版本的.Net Framework，就必须先删除1.0的。听说刚发行的.Net Framework1.1已经对1.0做了很多改进，甚至基础类库的层次也有所变动。看来在旧版本的.Net Framework开发的程序将来往新版本上面迁移的时候少不了修改程序代码。



二、JRE的基础类库 


JRE自带的基础类库主要是JRElibrt.jar这个文件，包括了Java2平台标准版的所有类库。和JRE的版本一致。



 .Net Framekwork的核心类库 


.Net Framekwork的核心类库被放置在C:Winntassemblygac目录下，按照不同的名称空间放在不同目录中，不像JRE打成了一个包。并且可以同时存在不同的版本，例如： 某类库1.0版本 C:Winntassemblygac名称1.0名称.dll 某类库1.1版本 C:Winntassemblygac名称1.1名称.dll



 这样做，虽然很灵活，可以随时把类库更新到最新的状态，但是很容易带来版本管理的复杂度，造成版本不一致。 


三、JRE类库的查找方法和版本管理



 JRE中由ClassLoader负责查找和加载程序引用到的类库，基础类库ClassLoader会到rt.jar中自动加载，其它的类库，ClassLoader在环境变量CLASSPATH指定的路径中搜索，按照先来先到的原则，放在CLASSPATH前面的类库先被搜到，Java程序启动之前建议先把PATH和CLASSPATH环境变量设好，[[OS]]通过PATH来找JRE，确定基础类库rt.jar的位置，JRE的ClassLoader通过CLASSPATH找其它类库。但有时候会出现这样的情况，希望替换基础类库中的类库，那么也可以简单的通过-Djava.endrosed.path=...参数传递给java.exe，于是ClassLoader会先于基础类库使用java.endrosed.path参数指定路径的类库。因此Java的版本管理是非常简单有效的，也许很原始，不过很好用，简单就不容易出错。(所以我很奇怪Eric Ramond为什么批评Java的类库管理机制，他还居然批评Java的接口，令人怀疑他对Java的了解程度) 


.Net Framework的类库管理机制



 .Net Framework的类库管理机制相当强大和复杂，分为私有类库和共享类库。  私有类库就放在exe程序当前路径下，或其相对路径中，只有当前程序可见。  共享类库需要在GAC(Global Assembly Cache)中注册，注册过程比较复杂，首先要用工具生成公开/私有密钥对，然后结合密钥和类库版本号连编，最后使用工具注册到GAC中好以后,会被放在"C:Winntassemblygac类库的名称空间版本号"目录下，不同的类库版本在注册的时候会按照版本号分开放置：  ·某类库1.0版本 C:Winntassemblygac名称1.0名称.dll  ·某类库1.1版本 C:Winntassemblygac名称1.1名称.dll 


也就是可以同时存在一个类库的n个版本，至于在程序中用哪个版本，在程序的配置文件中声明，CLR会根据声明来调用相应的版本的类库。我觉得.Net实现方法未免太复杂了一些，将所有共享类库都塞到一个系统目录下，并且同一个类库还有n个版本，将来.Net第三方开发的类库逐渐丰富起来以后，.Net类库的GAC也会越来越庞大，会不会也搞得和Windows注册表一样难以维护？软件发布到服务器上的时候，类库要再注册一次，服务器会逐渐形成一个庞大的树状的GAC，GAC里面存放着组件的n个版本。试想经过一段时间之后，C:Winntassemblygac目录会越来越庞大，有的组件甚至有n个版本都放在那里，你又不敢随便删除，不知道是不是有程序需要使用，我不明白MS为什么要把这么简单的事情搞到这么复杂？







[[Category:技術應用]]