更新时间：2022-08-25 17:02
JRE为Java Runtime Environment的简称，Java Runtime Environment（包括Java Plug-in）是Sun的产品，包括两部分：Java Runtime Environment和Java Plug-in。JavaRuntimeEnvironment(JRE)是可以在其上运行、测试和传输应用程序的Java平台。它包括Java虚拟机（jvm）、Java核心类库和支持文件。它不包含开发工具(JDK)--编译器、调试器和其它工具。JRE需要辅助软件--Java Plug-in--以便在浏览器中运行applet。
Java Plug-in软件允许Java Applet和JavaBean组件在使用Sun的Java Runtime Environment(JRE)的浏览器中运行，而不是在使用缺省的Java运行环境的浏览器中运行。Java Plug-in可用于Netscape Navigator和Microsoft Internet Explorer。
J2RE是Java2 Runtime Environment，即Java运行环境，只是强调其匹配Java2平台，有时简称JRE。如果你只需要运行Java程序或Applet，下载并安装它即可。如果你要自行开发 Java软件，请下载JDK(JRE和JDK的区别)。在JDK中附带有JRE。
Java的解决办法是每个程序自己携带一套JRE。
比如说某人的机器上已经被安装了好多套JRE和JDK(JDK包括了同版本的JRE，此外还包括有编译器和其它工具)，它们分别是：
BEAWeblogic Server 7.0 自带一套 JDK1.3.1_02， 还下载了一套最新的JDK1.4.1_02
JBuilder9自带一套JDK1.4.1_02
Oracle8.1.7自带一套JRE1.1.7
RationRose自带一套JDK1.3
DreamWeaver自带一套JDK1.3
6套JRE，每套JRE都被各自安装到不同的目录，不会互相影响。当在控制台执行java.exe，操作系统寻找JRE的方式如下：
先找当前目录下有没有JRE
再找父目录下有没有JRE
接着在PATH路径中找JRE
最常用的是在PATH路径中找JRE，一般情况下，自己的程序运行之前都会先在批处理文件里面临时设置PATH，把自己用的JRE放到PATH路径最前面，所以肯定会运行自己带的JRE，不会造成版本混乱。
，包括了Java2平台标准版的所有类库。和JRE的版本一致。
Net Framekwork的核心类库
名称空间放在不同目录中，不像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程序当前路径下，或其相对路径中，只有当前程序可见。
1、共享类库需要在GAC(Global Assembly Cache)中注册，注册过程比较复杂，首先要用工具生成公开/私有密钥名称空间\u7248本号"目录下，不同的类库版本在注册的时候会按照版本号分开放置：
2、可以同时存在一个类库的n个版本，至于在程序中用哪个版本，在程序的配置文件中声明，CLR会根据声明来调用相应的版本的类库。我觉得.Net实现方法未免太复杂了一些，将所有共享类库都塞到一个系统目录下，并且同一个类库还有n个版本，将来.Net第三方开发的类库逐渐丰富起来以后，.Net类库的GAC也会越来越庞大，会不会也搞得和Windows注册表一样难以维护？软件发布到服务器上的时候，类库要再注册一次，服务器会逐渐形成一个庞大的树状的GAC，GAC里面存放着组件的n个版本。
全局程序集缓存不会是无限大的，所以“将来.Net第三方开发的类库逐渐丰富起来以后，.Net类库的GAC也会越来越庞大，会不会也搞得和Windows注册表一样难以维护？”这是杞人忧天。原因如下：第一是操作系统的生命周期一般不会是无限长的，而且越来越短，Windows为证，同时.Net Framework也在不断更迭，在十年左右的时间里，全球的程序产量是有限的，高质量的第三方开发的类库更是有限，需要注册到GAC的就更少了。
Java运行时环境与Java平台
尽管Java Runtime Environment是Java平台的一部分，但Java Runtime Environment不应与Java平台合并。原因是，Java平台是一般的东西，但Java Runtime Environment是一个SPECIFIC组件，就像Java Development Kit一样。
Java Runtime Environment不是“来自Sun”
遗憾的是，这篇文章不仅是错误的，而且传播了错误观念，即运行Java需要Sun Microsystems：<<“Java Runtime Environment，或JRE，是Sun Microsystems的软件包，它允许计算机系统运行Java应用程序。”>>Sun实际上拥有（* note1）Java规范，但任何人（* note2）都可以编写Java Runtime实现。（注意1：好的，确定，有JCP，但实际上Sun拥有该语言。）（注2：好的，不是任何人;编写实现的人必须承诺不破坏规范（例如，像微软试图做的那样）通过许可Sun的规范 - 但这只是实现虚拟机的权利。）。
在sun.com下载页面上，当前版本是“Java（TM）SE Runtime Environment 6”。java.com测试页要我更新到“版本6更新2”。我安装的版本是最近的（几周），但版本号为1.5.0_11。
-87.162.24.12610：46，2007年7月24日（UTC）
通过阅读长期存在的bugzilla 83376（自2001年以来）追踪了Java引发FF2异常的可能原因看起来Sun的Java插件（甚至是最新版本）在FF2下使用了useragent（UA）欺骗（仍然一些网站所需要的，因为，用Sun自己2001年的话来说：“Java插件依赖于用户代理字符串来获取版本信息，不会做出修复。”很好，最后。这意味着FF的UA必须在启动时默认（不是欺骗）。如果FF的UA被欺骗，那么下次FF启动时Java会引发异常。尴尬，但至少我现在有一个解决方法修复。
奇怪的是，JRE术语（这个术语很常见）会重定向到Java虚拟机，而Java虚拟机主要由已经知道Java是什么的人使用。似乎更好地解释什么是JRE，并在那里提供wiki链接。