http://luohaiyong1024.blog.163.com/blog/static/2682797201231104615287/
電腦上裝了兩個版本的JDK，分別是Jdk1.5u6和Jdk1.6u29，打開命令行窗口，輸入
java -version
命令，顯示的當前使用Jdk版本號是1.6，由於測試需要將當前JDK環境變量設爲1.5，但通過一般的環境變量設置或修改註冊表，均不成功。在網上找了相關資料，發現是因爲在安裝JDK1.6時，自動將java.exe、javaw.exe、javaws.exe三個可執行文件複製到了C:\Windows\System32目錄，由於這個目錄在WINDOWS環境變量中的優先級高於JAVA_HOME設置的環境變量優先級，後將JDK1.5的bin目錄放置在path環境變量的最開始位置（即在C:\Windows\System32環境變量前面）後解決問題。以下是參考資料：
原文鏈接：http://www.iteye.com/topic/4387
----------------------------------------------------------
我以前寫的文章，貼出來和大家共享
Java2 SDK安裝對註冊表的修改
Written by anson 2002-8-23
將會生成如下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。