Registry key ‘Software/JavaSoft/Java Runtime Environment/CurrentVersion’

今天開啟Eclipse的時候，突然出現了問題，程式總是崩潰，一直打不開eclipse。重啟多次，也不行，鬱悶~

 

使用命令列，java -version，顯示如下結果：

C:/>java -version

Registry key 'Software/JavaSoft/Java Runtime Environment/CurrentVersion'

has
value '1.3', but '1.6' is required.

Error: could not find java.dll

Error:
could not find Java SE Runtime Environment

再試試j
avac，似乎有一切正常，很納悶。

 

閱讀上面的錯誤提示，貌似是註冊表裡面的CurrentVersion的值設定的不對。但是我在註冊表裡又未能找到對應的這個索引值。

 

從google上面搜了一下，大多都是讓手動改CurrentVersion索引值的方法（我差點自己手動建立這麼個索引值）。不過有一篇文章講的很全面，很受啟發。

 

原來是昨天安裝的oracle8.1的驅動到的亂，安裝它之後，它會將自身帶著的jdk1.1的路徑加入Path環境變數。找到問題所在，改了Path的順序，問題解決了。具體細節，參考下面轉載文章。

 

轉載地址：http://java.chinaitlab.com/Jvm/21229.html

 

 

關於 java.exe 是如何載入 JVM

 

將會產生如下3個項目：

　　HKEY_LOCAL_MACHINE/SOFTWARE/Java

Soft/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。