Registry Key 'Software/container oft/Java Runtime Environment/currentversion'

Today, when eclipse was opened, a problem suddenly occurred, and the program always crashed and eclipse was never opened. It won't work if I restart it multiple times. It's depressing ~

 

Use the command line and Java-version to display the following results:

C:/> JAVA-version

Registry Key 'Software/container oft/Java Runtime Environment/currentversion'

Has
Value '1. 3', but '1. 6' is required.

Error: cocould not find java. dll

Error:
Cocould not find Java SE Runtime Environment

Try J again
Avac, it seems that everything is normal, very puzzled.

 

Read the error message above. It seems that the value of CurrentVersion in the registry is incorrect. However, I cannot find the corresponding key value in the registry.

 

I searched from Google and found that most of the methods were to manually change the CurrentVersion key value (I almost manually set this key value ). However, an article is very comprehensive and inspired.

 

It turns out that the oracle8.1 driver installed yesterday is messy. After installing it, it will add its own jdk1.1 path to the path environment variable. Locate the problem, change the path sequence, and solve the problem. For details, refer to the following article.

 

Address: http://java.chinaitlab.com/Jvm/21229.html

 

 

How java.exe loads JVM

 

The following three projects are generated:

HKEY_LOCAL_MACHINE/software/Java

Soft/Java

Development Kit

HKEY_LOCAL_MACHINE/software/javasoft/Java Plug-in

HKEY_LOCAL_MACHINE/software/kerberoft/Java Runtime Environment

　　

　
In addition, Java2
The sdkinstaller copies the three executable files java.exe, javaw.exe, and javareg.exe to the WINNT/system32 directory.
Winnt/system32is set as the pathsearch criterion with the highest priority for the operating system. This ensures that the user can run java.exe to start
JVM.

　　

How can I determine the directory where JRE is located and the link library that needs to be dynamically loaded when java.exe is started? Java.exe is determined by the following method:

　　

　
If the ../JRE/bin/Java. dll file exists, search for./JRE/lib/
In the jvm.htm file, the 1th column of jvm.dll.pdf is set to the threshold value. If the JVM. dll type is specified on the java.exe command line, the specified class is used.
Type ). JVM. dll types include hotspot, classic, and server. If the ../JRE/lib/JVM. cfg file does not exist, print the following error
Incorrect information:

　　

Error: cocould not open 'C:/jdk1.3/JRE/lib/JVM. cfg'

　　

　
If ../JRE/bin/Java. dll does not exist (when winnt/system32/java.exe is running ),
Use, HKEY_LOCAL_MACHINE/software/javasoft/Java Runtime Environment/
The CurrentVersion key value is actually the version value of WINNT/system32/java.exe. This version value only stores the master and secondary versions, as shown in
1.2, 1.3, etc.

　　

At the same time, the java.exe program itself also has a version value that identifies itself, such as 1.2 and 1.3. Java.exe
The internal version value is compared with the CurrentVersion value. If two values are found to be equal
/Define oft/Java Runtime
Under environment/mainversion. microversion, obtain the JRE directory and dynamic link library. The two keys are named javahome respectively.
And runtimelib. mainversion indicates the main version number and microversion indicates the minor version number.

　　

If the internal version of java.exe is different from CurrentVersion, an error similar to the following is returned:

　　

Registry Key 'Software/container oft/Java Runtime Environment/currentversion'

Has value '1. 2', but '1. 3' is required.

　　

　
This means that the WINNT/system32/java.exe8.0 currently recorded in the registry is 1.2, but the java. EXE version running on the registry is 1.3.
Java.exe complained that the JRE directory and JVM. dll cannot be correctly located unless the Registry has a 1.3 record. Therefore, it is necessary to prompt 1.3.

　　

　
Here, we cannot simply modify the CurrentVersion value of the registry to achieve this goal. Generally, when two sets of Java2 are installed in the system
SDK (for example, first install 1.2 and then install 1.3), followed by Java2
Sdkcopies the existing java.exeand javaw.exe files to the WINNT/system32directory, and overwrites the existing java.exe and
Javaw.exe, and in the registry, rewrite CurrentVersion to 1.3. Therefore, we recommend that you install Java2
Uninstall the previously installed version before using the SDK. If you modify currentversionby others, the Java. dll and
JVM. dll will cause unpredictable consequences!

　　

　　Special cases:

JBuilder has its own JDK. After JBuilder is installed, the JBuilder installer changes CurrentVersion to the JDK version, but does not overwrite java.exeand javaw.exe under winnt/system32.

　　

WebLogic has a set of JDK. After Weblogic is installed, the Weblogic installer does not modify the registry or overwrite java.exeand javaw.exe under winnt/system32.

　　

Oracle

Bring your own JDK (usually a relatively low version, for example, 8.1.7 only includes JDK 1.1.7 ).

Security
After the installation is complete, the Oracle installer does not modify the registry, nor overwrite java.exeand javaw.exe under winnt/system32. However, oralce
The installer modifies the system PATH variable, adds the bin path of the built-in JRE to it, and puts it at the beginning. With different Oracle Installation versions, their JRE-embedded JVM startup programs are also
Different. In Oracle 8.1.7 installed on the author's machine, its JRE is installed under C:/program files/Oracle, and C:/Program
Files/Oracle/JRE/1.1.7/binat the top of pathvariation, The jvmboot program is jre.exeand not java.exe.

　　

The above is the Java2 SDK in Windows

The following actions during installation will cause compatibility issues:

　　

Problem Background: After the Java2 SDK is installed, jbuilder6 is installed and no PATH variable is modified.

　　

　　Question 1

When JDK 1.2 is installed in the operating system and jbuilder6 (with JDK 1.3.1) is installed, CurrentVersion is 1.3. When you execute Java-version on the command line, the following message is displayed:

　　

Registry Key 'Software/container oft/Java Runtime Environment/currentversion'

Has value '1. 3', but '1. 2' is required.

　　

Solution: add the path of java.exe in JDK 1.2to the top of the operating system path to ensure that java.exein JDK 1.2is always executed when Java is called through the command line, so that java.exe can correctly locate JRE and JVM. dll.

　　

　　Question 2

　
After JDK 1.3.0 is installed in the operating system, jbuilder6 is installed.
1.3.1). At this time, CurrentVersion is 1.3, but this 1.3 point to the JDK that comes with jbuilder6.
JRE of 1.3.1, instead of pointing to the JRE of JDK 1.3.0. When Java-version is executed on the command line
1.3.0 copies java.exe to winnt/system32, but the printed version information is:

　　

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)

　　

The original cause of this question is that java.exe only maintains the version number of the first digit after the decimal point, rather than the second digit.

　　

　　Solution: Same as problem 1

　　Question 3:

　
If JDK 1.3.0 is installed first in the operating system, then jbuilder6 (with JDK
1.3.1, the first two are the same), then issue 1 is actually hidden and there is no chance to happen. Problem 2 is also concealed and difficult to detect, because JDK 3rd versions are often ignored.

　　

　
As described in question 2, Java is executed on the command line, Although JDK is used
1.3.0a copy of java.exe (in the WINNT/system32 directory), but it actually uses JDK under jbuilder6
1.3.1 JRE and its directory structure. The result is that when we use the extension mechanism of Java2 to put the JAR file to JDK
The JRE/lib/EXT directory of 1.3.0 cannot achieve the desired effect.-When the command line starts a program using Java, the JDK
The JRE/lib/EXT directory of 1.3.0 is used to search for the JAR file. It only goes to JDK 6 under jbuilder6.
JRE/lib/ext of 1.3.1 searches for jar files, while JDK 1.3.1 under jbuilder6 does not have a directory such as JRE/lib/EXT!

　　

Problem 3 is extremely concealed. Unless you fully understand the installation of the Java2 SDK and the class positioning mechanism, it is difficult for general developers to find the problem. For more information about the class positioning mechanism in Java2, see the article "class positioning mechanism in Java2.

　　

　
In fact, even if there is only one JDK 1.3.0 in the system, if you run Java on the command line, the JRE directory used is C:/program.
Files/program oft/JRE/1.3, that is, even if we place our extension under C:/jdk1.3/JRE/lib/EXT
Jar. The correct method is to put it in the C:/program files/unzip oft/JRE/1.3/lib/EXT directory.

　　

　　Solution: Same as problem 1

To sum up, we strongly recommend that you put % jdk_home %/bin directory in Windows

The first of the PATH variable in the operating system to avoid potential problems.

　　

In UNIX, there is no problem similar to the Windows operating system.

　　

The Java we run in the command is/bin/Java

　　

$ Which Java

$/Bin/Java

　　

While/bin is the link to/usr/bin, that is,/bin/Java is actually/usr/bin/Java

　　

While/usr/bin/Java actually links to/usr/Java/bin/Java, /usr/Java is the link to/usr/java1.2 (Solaris 7 or higher built-in JDK 1.2), so what we actually execute is

　　

/Usr/java1.2/bin/Java

　　

　
Based on UNIX, Java can always use ../JRE/lib/iSCSI/libjava. So and ../JRE/lib/
/Libjvm. So to find these two files. The former is similar to Java. dll in windows, and the latter is similar to JVM. dll in windows. So Java
You can always determine your own JRE directory.

　　

The dynamic link library used on Windows and UNIX is actually called optional in Sun's document.
Package's native code binaries, optional pakage is actually extension mechanic
Classes. For details, see "class locating mechanism in Java2".

　　

To change the Java version on UNIX, the link to/usr/Java is one of the methods. For details, see the installation of JDK on UNIX.

　　

Supplement: (2002-12-23)

　　

How to locate plug-in Windows

　　

　
Find the java. EXE version number in the pathenvironment variable, go to HKEY_LOCAL_MACHINE/software/javasoft/Java
Find the corresponding version of Java Plug-in under plug-in.
Multiple versions of plug-in can exist in plug-in.

　　

Does not rely on HKEY_LOCAL_MACHINE/software
/Export oft/Java Development
The CurrentVersion value of KIT and HKEY_LOCAL_MACHINE/software/export oft/Java Runtime
The CurrentVersion value of environment to locate the Java Plug-in version to be used.