将会生成如下3个项目：
　　hkey_local_machine/software/javasoft/java development kit
　　hkey_local_machine/software/javasoft/java plug-in
　　hkey_local_machine/software/javasoft/java runtime environment
　　
　　同时，java2 sdk安装程序将会把java.exe，javaw.exe，javareg.exe这3个可执行文件拷贝到winnt/system32目录下，由于winnt/system32被操作系统缺省的设置为最高优先权的path搜索路径，因此可保证用户在命令行任何目录下可运行java.exe来启动jvm。
　　
　　那么java.exe在启动时如何确定其jre所在的目录以及需要动态加载的链接库呢？java.exe是通过下面方式来确定的：
　　
　　假如存在../jre/bin/java.dll文件，则查找../jre/lib/ jvm.cfg文件，在该文件中，第1个被列出的jvm.dll类型作为缺省值（假如在java.exe命令行指定了jvm.dll的类型，则使用指定类型）。jvm.dll类型分为hotspot，classic，server三种。假如不存在../jre/lib/jvm.cfg文件，则打印下面的错误信息：
　　
　　error: could not open 'c:/jdk1.3/jre/lib/jvm.cfg'
　　
　　如不存在../jre/bin/java.dll（当运行的是winnt/system32/java.exe），则注册表将在此时发挥作用，hkey_local_machine/software/javasoft/java runtime environment/ currentversion键值所记录的实际上是winnt/system32/java.exe的版本值，该版本值只保存主、次两个版本号，如1.2，1.3等。
　　
　　同时java.exe程序内部本身也有一个标识自身的版本值，如1.2、1.3等。java.exe根据自己内部的版本值和currentversion值相比较，如果发现两个值相等，则将在hkey_local_machine/software/javasoft/java runtime environment/mainversion.microversion项下获取jre所在目录及动态链接库，这两个键的名称分别是javahome和runtimelib，mainversion表示主版本号，microversion表示次版本号。
　　
　　如果java.exe内部版本值和currentversion不一致，则报类似以下的错误：
　　
　　registry key 'software/javasoft/java runtime environment/currentversion'
　　has value '1.2', but '1.3' is required.
　　
　　意思是说，注册表当前所记载的winnt/system32/java.exe版本为1.2，但是此时运行的java.exe版本为1.3。java.exe抱怨除非注册表有1.3版的记载，否则自己无法正确定位jre目录和jvm.dll，因此提示1.3是需要的。
　　
　　这里，我们不能简单的修改注册表的currentversion值来达到这个目的。一般地，当在系统中装了两套版本的java2 sdk（如先装1.2而后又装了1.3），后面安装的java2 sdk会将自己带的java.exe和javaw.exe拷贝到winnt/system32目录下，从而覆盖先前版本的java.exe和javaw.exe，并且在注册表中改写currentversion为1.3。所以建议在安装java2 sdk前，先卸载以前安装的版本。如果人为的修改currentversion，会使得不同版本的java.exe加载与己版本不符的java.dll及jvm.dll，将引起难以预料的后果！
　　
　　特殊情况：
　　jbuilder自己带一套jdk，在jbuilder安装完成后，jbuilder安装程序会修改currentversion为自己所带jdk的版本，但不会覆盖winnt/system32下的java.exe和javaw.exe。
　　
　　weblogic自己带一套jdk，在weblogic安装完成后，weblogic安装程序不会修改注册表，也不会覆盖winnt/system32下的java.exe和javaw.exe。
　　
　　oracle自己带一套jdk（一般是比较低版本的，例如8.1.7仅仅带jdk 1.1.7），在oracle安装完成后，oracle安装程序不会修改注册表，也不会覆盖winnt/system32下的java.exe和javaw.exe。但是，oralce安装程序会修改系统path变量，将自带的jre的bin路径加入其中，且置于最前面。随着oracle安装版本的不同，其自带jre的jvm启动程序也不同。在笔者机器上安装的oracle 8.1.7，其jre就装在c:/program files/oracle下，并将c:/program files/oracle/jre/1.1.7/bin放在path变量最前，其jvm启动程序是jre.exe而非java.exe。
　　
　　以上就是java2 sdk在windows下安装时所做的动作，这样会带来兼容性问题：
　　
　　问题背景：安装java2 sdk后，安装了jbuilder6，未修改任何path变量
　　
　　问题1
　　当在操作系统中安装了jdk 1.2，其后安装了jbuilder6（自带jdk 1.3.1），这时currentversion为1.3，在命令行执行java -version时，提示：
　　
　　registry key 'software/javasoft/java runtime environment/currentversion'
　　has value '1.3', but '1.2' is required.
　　
　　解决方法：将jdk 1.2中java.exe所在路径加入到操作系统path的首位，从而保证在命令行调用java时总是执行jdk 1.2中的java.exe，以使得java.exe可正确定位jre和jvm.dll。
　　
　　问题2
　　当在操作系统中安装了jdk 1.3.0，而后安装了jbuilder6（自带jdk 1.3.1），这时currentversion为1.3，但是此1.3是指向的是jbuilder6自带的jdk 1.3.1的jre，而非指向先前jdk 1.3.0的jre，当在命令行执行java -version时，此时执行的是jdk 1.3.0拷贝到winnt/system32的一个java.exe副本，但打印的版本信息却是：
　　
　　java version "1.3.1"
　　java(tm) 2 runtime environment, standard edition (build 1.3.1-b24)
　　java hotspot(tm) client vm (build 1.3.1-b24, mixed mode)
　　
　　导致该问题的原因是java.exe只维护小数点后1位的版本号，而非2位。
　　
　　解决方法：同问题1
　　问题3：
　　如果在操作系统中先安装了jdk 1.3.0，而后安装了带有与安装jdk主次版本相同的jbuilder6（带jdk 1.3.1，前两位相同），则问题1实际上被隐蔽了，没有发生的机会；而问题2的隐蔽性也很强，不容易发觉，因为人们往往会忽略jdk的第3个版本号。
　　
　　如问题2所叙，在命令行执行java，虽然是使用jdk 1.3.0的一个java.exe副本（winnt/system32目录下），而实际上却是使用jbuilder6下jdk 1.3.1的jre及其目录结构，其结果是当我们使用java2的extension mechanism将jar文件放到jdk 1.3.0的jre/lib/ext目录下时，发现达不到希望的效果 ? 在命令行用java启动程序时，不会自动去jdk 1.3.0的jre/lib/ext目录下去搜索jar文件，它只会去jbuilder6下jdk 1.3.1的jre/lib/ext去搜索jar文件，而jbuilder6下的jdk 1.3.1并不存在jre/lib/ext这么一个目录！
　　
　　问题3极为隐蔽，除非完全对java2 sdk的安装及class定位机制了解，一般的开发者是难以发现问题所在的。有关java2中class定位机制，见《java2中的class定位机制》一文。
　　
　　事实上，即使仅仅在系统中存在一份jdk 1.3.0，如果在命令行运行java的话，使用的jre目录是c:/program files/javasoft/jre/1.3，也就是说，即使我们在c:/jdk1.3/jre/lib/ext下放置我们的extension jar，也得不到预期的结果。正确的做法是放在c:/program files/javasoft/jre/1.3/lib/ext目录下。
　　
　　解决方法：同问题1
　　综上所叙，强烈建议将%jdk_home%/bin目录放在windows操作系统的path变量的首位，以避免潜在的问题。
　　
　　而在unix下，则完全不存在类似windows操作系统上的问题。
　　
　　我们在命令下执行的java是/bin/java
　　
　　$which java
　　$/bin/java
　　
　　而/bin是到/usr/bin的链接，也就是说/bin/java实际上是/usr/bin/java
　　
　　而/usr/bin/java实际上链接到/usr/java/bin/java，/usr/java是到/usr/java1.2的链接（solaris 7或更高系统内置jdk 1.2），所以我们实际上执行的java是
　　
　　/usr/java1.2/bin/java
　　
　　根据unix上的情况，java在运行时实际上总是可以用../jre/lib/sparc/libjava.so和../jre/lib/sparc/libjvm.so来找到这2个文件，前者类似于windows下的java.dll，而后者类似于windows下的jvm.dll。所以java也总是可以确定自己jre的目录。
　　
　　windows和unix上用到的动态链接库，实际上在sun的文档中称为optional package's native code binaries，optional pakage实际上即为extension mechanism classes，详见《java2中的class定位机制》。
　　
　　要更改unix上java的版本，更改/usr/java的链接是其中一个方法，具体可参见jdk在unix上的安装介绍。
　　
　　补充：（2002-12-23）
　　
　　windows如何定位plug-in
　　
　　根据在path环境变量中找到的java.exe的版本号，到hkey_local_machine/software/javasoft/java plug-in下寻找对应版本的java plug-in，在hkey_local_machine/software/javasoft/java plug-in下可以有多个版本的plug-in存在。
　　
　　不依赖hkey_local_machine/software/javasoft/java development kit的currentversion值和hkey_local_machine/software/javasoft/java runtime environment的currentversion值来定位应该使用哪个版本的java plug-in。