Error: cocould not open 'C: \ porogram files \ Java \ jrelib \ j386 \ JVM. cfg'

Error: cocould not open 'C: \ porogram files \ Java \ jrelib \ j386 \ JVM. cfg'
I don't know why. After I reinstall it, I can view the javac-version, but the Java-version won't work. I always report a title error! After a long time, I finally solved the problem...

JDK will generate the following three projects during the installation process:
HKEY_LOCAL_MACHINE \ SOFTWARE \ javasoft \ Java Development Kit
HKEY_LOCAL_MACHINE \ SOFTWARE \ javasoft \ Java Plug-in
HKEY_LOCAL_MACHINE \ SOFTWARE \ javasoft \ Java Runtime Environment

At the same time, the jdkinstaller will copy the three executable files java.exe, javaw.exeand javareg.exe to the winnt \ system32 directory, and start JVM due to winnt \ drivers.

Java.exe is determined by the following method at startup:

If the ../JRE/bin/Java. dll file exists, the JVM. dll type is specified by the ../JRE/lib/classes command line ). JVM. dll types include hotspot, classic, and server. If the ../JRE/lib/JVM. cfg file does not exist, print the error message you mentioned:

If not .. /JRE/bin/Java. DLL (when running winnt \ system32 \ java.exe), the Registry will play a role at this time, HKEY_LOCAL_MACHINE \ SOFTWARE \ kerberoft \ Java Runtime Environment \ CurrentVersion the key value is actually the version value of WINNT \ system32 \ java.exe. The version value only saves the master and secondary version numbers, such as 1.2 and 1.3.

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 compares the internal version value with the CurrentVersion value. If two values are found to be equal, they will be in HKEY_LOCAL_MACHINE \ SOFTWARE \ javasoft \ Java Runtime Environment \ mainversion. obtain the directory where the JRE is located and the dynamic link library under the microversion item. The two keys are named javahome and runtimelib respectively. 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 \ kerberoft \ 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 sdks are installed in the system (for example, 1.2 is installed first and 1.3 is installed later), the Java2 packages installed later are copied to the WINNT \ system32directory, covering the java.exe and javaw.exe of the previous version from the beginning, in the registry, change CurrentVersion to 1.3. Therefore, we recommend that you uninstall the previously installed version before installing the Java2 SDK. If you modify currentversionby others, the Java. dll and JVM. dll versions that are not consistent with the current version will be loaded, which 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 has its own JDK (usually a relatively low version, for example, 8.1.7 only has JDK 1.1.7). After oracle is installed, the Oracle installer does not modify the registry, it will not overwrite java.exe and javaw.exe under winnt \ System32. However, the oralce 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 built-in jre jvm startup programs are also different. The JRE of Oracle 8.1.7 installed on the author's machine is installed under C: \ Program Files \ oracle, and c: \ Program Files \ oracle \ JRE \ 1.1.7 \ binis placed before pathvariables, and its jvmboot program is jre.exeand not java.exe.

The above is the action performed by the Java2 SDK during installation in windows, which will bring about 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 \ kerberoft \ 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
When JDK 1.3.0 is installed in the operating system, and then jbuilder6 (with JDK 1.3.1) is installed, CurrentVersion is 1.3, but this 1.3 points to the JRE of JDK 1.3.1 of jbuilder6, instead of pointing to the previous JDK 1.3.0 JRE, when Java-version is executed on the command line, JDK 1.3.0 is executed to copy 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, and then jbuilder6 (with JDK 1.3.1 and the first two versions are the same) is installed, issue 1 is actually hidden, there is no chance to happen. Problem 2 is also very concealed and hard to detect, because people tend to ignore the 3rd JDK version.

As described in question 2, although Java is executed on the command line using a copy of java.exe of JDK 1.3.0 (under the WINNT \ system32 directory), it actually uses the JRE and its directory structure of JDK 1.3.1 under jbuilder6, the result is that when we put the JAR file under the JRE \ Lib \ ext directory of JDK 1.3.0 using the extension mechanism of Java2, failed to achieve desired results-when the command line starts the program using Java, it will not automatically go to the JRE \ Lib \ ext directory of JDK 1.3.0 to search for the JAR file, it only searches for jar files from JRE \ Lib \ ext under JDK 1.3.1 under jbuilder6, 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 \ mongooft \ JRE \ 1.3, that is, even if we place our extension jar under c: \ jdk1.3 \ JRE \ Lib \ Ext, we cannot get the expected results. 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
In summary, it is strongly recommended that the % jdk_home % \ bin directory be placed first in the PATH variable of the Windows 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 be used at runtime .. /JRE/lib/iSCSI/libjava. so and .. /JRE/lib/iSCSI/libjvm. so to find the two files, the former is similar to the java. DLL, which is similar to the JVM in windows. DLL. Therefore, Java can always determine its own JRE directory.

The dynamic link library used on Windows and UNIX is actually called Optional package's native code binaries in Sun's documents. Optional pakage is actually extension mechanic classes, for details, see "class positioning 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:

How to locate plug-in Windows

Find the java.exe version number in the pathenvironment variable and find the corresponding Java Plug-in version under HKEY_LOCAL_MACHINE \ SOFTWARE \ ft oft \ Java Plug-in, multiple versions of plug-in can exist in HKEY_LOCAL_MACHINE \ SOFTWARE \ javasoft \ Java Plug-in.

It does not depend on the CurrentVersion value of HKEY_LOCAL_MACHINE \ SOFTWARE \ javasoft \ Java Development Kit and the CurrentVersion value of HKEY_LOCAL_MACHINE \ SOFTWARE \ javasoft \ Java Runtime Environment to determine which version of Java Plug-in should be used.

I have written a lot of data on it before I can read it. Now I have copied it.

Let's just talk about the solution:

Registry-> HKEY_LOCAL_MACHINE-> Software \ javasoft \ All javahome key values under the subdirectory are changed to the JRE absolute path under the newly installed JDK directory