学步园

JRE的地位就象一台PC机一样，我们写好的Win32应用程序需要操作系统帮我们运行，同样的，我们编写的Java程序也必须要JRE才能运行。所以当你装完JDK后，如果分别在硬盘上的两个不同地方安装了两套JRE，那么你可以想象你的电脑有两台虚拟的Java PC机，都具有运行Java程序的功能。所以我们可以说，只要你的电脑安装了JRE，就可以正确运行Java应用程序。

1、为什么Sun要让JDK安装两套相同的JRE？
这是因为JDK里面有很多用Java所编写的开发工具（如javac.exe、jar.exe等），而且都放置在 <JDK安装目录>/lib/tools.jar 里。从下面例子可以看出，先将tools.jar改名为tools1.jar，然后运行javac.exe，显示如下结果：
Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/tools/javac/Main
这个意思是说，你输入javac.exe与输入

java -cp c:/jdk/lib/tools.jar com.sun.tools.javac.Main

是一样的，会得到相同的结果。
从这里我们可以证明javac.exe只是一个包装器（Wrapper），而制作的目的是为了让开发者免于输入太长的指命。而且可以发现<JDK安装目录>/lib目录下的程序都很小，不大于29K，从这里我们可以得出一个结论。就是JDK里的工具几乎是用Java所编写，所以也是Java应用程序，因此要使用JDK所附的工具来开发Java程序，也必须要自行附一套JRE才行，所以位于C:/Program Files/Java目录下的那套JRE就是用来运行一般Java程序用的。

2、如果一台电脑安装两套以上的JRE，谁来决定呢？
这个重大任务就落在java.exe身上。Java.exe的工作就是找到合适的JRE来运行Java程序。
Java.exe依照底下的顺序来查找JRE：
自己的目录下有没有JRE；
父目录有没有JRE；
查询注册表：
[HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft/Java Runtime Environment]
所以java.exe的运行结果与你的电脑里面哪个JRE被执行有很大的关系。

3、介绍JVM
JRE目录下的Bin目录有两个目录：server与client。这就是真正的jvm.dll所在。
jvm.dll无法单独工作，当jvm.dll启动后，会使用explicit的方法（就是使用Win32 API之中的LoadLibrary()与GetProcAddress()来载入辅助用的动态链接库），而这些辅助用的动态链接库（.dll）都必须位于jvm.dll所在目录的父目录之中。
因此想使用哪个JVM，只需要设置PATH，指向JRE所在目录底下的jvm.dll。 

==================================================================================

我们可以通过helloworld来理解这几个缩写词的具体含义：

public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("helloworld");
  }
}

编译之后， 我们得到了HelloWorld.class（图中的"Your program's class files"）
在HelloWorld里面， 我们调用了 JAVA API中的 java.lang.System这个类的静态成员对象 out, out 的静态方法: public static void println(String string);

然后我们让虚拟机器来执行这个HelloWorld。
1. 虚拟机会在classpath中找到HelloWorld.class。
2. 虚拟机中的解释器(interpret)会把HelloWorld.class解释成字节码。
3. 把解释后的字节码交由execution engin执行。
4. execution engin会调用native method(即平台相关的字节码）来在host system的stdout(显示器)的指定部分打印出指定的字符串。
5. 这样， 我们就看到"helloworld"字样了。

有了这个流程后， 我们就好理解上面几个术语了：
a. JDK: java develop kit (JAVA API包)
b. SDK: software develop kit, 以前JDK 叫做java software develop kit， 后来出了1.2版本后， 就改名叫jdk了， 省时省力， 节约成本。
c. JRE. java runtime environment 我们的helloworld必须在JRE(JAVA运行环境,JAVA运行环境又叫JAVA平台）里面， 才能跑起来。 所以， 显然地， JRE其实就是JDK + JVM

d. JVM java virtual machine. 简单地讲， 就是把class文件变成字节码， 然后送到excution engin中执行。 而为什么叫虚拟机， 而不叫真实机呢？ 因为JVM本身是又不能运算， 又不能让显示器显示"helloworld"的， 它只能再调用host system的API， 比如在w32里面就会调c++的API， 来让CPU帮他做做算术运算， 来调用c++里面的API来控制显示器显示显示字符串。 而这些API不是JDK里面有的，我们平时又看不见的，所以我们就叫它native api了（亦曰私房XX）。

e. 解释平台无关。 有人会说， 在linux的里面调用native api与w32里面调用的api肯定不一样吧？ 那为什么说JAVA是平台无关的呢？
其实是这样的， 君不见java.sun.com里面又有jdk-for-w32又有jdk-for-linux下载吗？ 刚才不是说了吗？ native api, native api, 就是我们平时看不见的api吗！ 调用native这些烦琐的活儿都让jdk去做了。 所以我们调用的时候只用知道jdk(java api) 里面的java.io.*能提供磁盘访问功能， java.awt.* 能画个框框画个圆圆就行了吗。 至于JDK又是怎么调用的， 在LINXU上更圆呢？ 还是在W32上更圆，(x) 这个就是JDK个人的事情了。（理论上讲是一样圆的， 当然这又和显示器是否纯平相关了:D)

同时， 这里就引申出了另一个话题。 既如何编写平台无关的JAVA程序。 其中关键的一条， 就是调用且只调用jdk中的API， 而不要私自调用native api。 原因很简单啊， JDK-for-linux和JDK-for-w32表面都是一样的， 所以我在w32里面调用JDK写的java程序，在linux里面也会一样的写法啊， 所以就可以移植来移植去都没问题。(b) 但是如果我在w32里面调用了 一个图形显示的native api, 当我移植到linux去的时候， 谁又能保证里面也有相同名称， 相同参数，相同返回值， 相同功能的native api供我调用呢！(?)