"Java Depth Adventures" introduced Javac.exe is a wrapper class, in fact, Javac.exe is also implemented in the Java language, then it is required to run the JRE support, so
There is a JRE in the Java installation directory, as shown in to support Javac execution.
So what kind of JRE should java.exe use? You can specify it yourself. The book describes a process that, when executing the command Java.exe, "first the run directory of the command should be added to path, or add absolute path to the command" in the red line, if after downloading the JDK, the Java option will appear after the path is added. If you delete the above two and confirm that there is no java.exe in the C:\Windows\system32,here about C:\Windows\system32 another experiment, in the last, you need to restart the command terminal after modifying the system variables. Then the system will prompt (the red circle in the figure is I changed Java_path to "" after the content, indicating that the java.exe can not be found, the result is not recognized ' java ' command) and then I add ' Java installation directory \ Bin ', this time should be able to find the Java command, and the prompt option if the input-version will show the current JRE version now returns to the book about the JRE explanation. The book shows that the path to finding the JRE according to Java.exe is 1. Find out if Java.exe has a JRE file in the same directory "the text says it is inaccurate, but does not give a clear explanation" 2. Find out if there is a jre3 in the Java installation directory. Find the JRE address in the registryWindows Registry (
hkey_local_machine\software\javasoft\java
Runtime environment\ )
Well, now I'm going to start with one and test it.
First, the JDK1.8 included in the JRE to join Jave.exe with the directory, java-version out the results are still no matter how much, I do not understand. For the first moment, as the book says in 1, it is inaccurate to say in the same catalogue. Next, experiment the second article. I renamed the JRE file under JDK 7 to jre_1.7, and I copied the JDK1.8 JRE into the directory, and then we tested the Java-versionok, and now it's 1.8, and the result is good, the instructions are right, that's it. And then, let's take a look at the registry. Open the Registry registry with Regedt32.exe I don't know what that means. But in order to test the registry, I have invalidated all two of the previous conditions. Oh, wait, I think the JRE lookup may also be able to pass through the path of the system variable, then the first two are invalidated, and then the path of the JRE is added. "Variables that are set in the user variable are not readable in the system variables;" In the Red Line directory, there is a JRE, which is version 1.8, and now we can try to succeed.
The result should be no, then it is said that the JRE is not accessed through path, and is related to the directory where Java.exe is located.the error in the above red line occurs because I modified the JRE address in the registry. Now that this error has occurred, it's time to start looking for the registry. This is the 1.7 version of the registry in the same, jre7_1 address is wrong, that is caused by the above could not open the cause of the error. Again, the version address of this JRE is not in the JDK installation directory, but is the additional JRE selected at the time of installation. When the modifications are complete, the results indicate that they are actually found through the registry. The final book has a topic, it is necessary to create this problem is easy Ah, modify the registry of the CurrentVersion become 1.8 on the line. But here, I do not understand the process of the registry, the book explained that the version is pointing to the corresponding configuration "figure 1.8 corresponds to just for convenience, too lazy to modify", should be no problem, because the wrong JRE address we modified earlier is the modified 1.7 address. But this question makes me wonder where 1.7required comes from, because Java.exe is in the 1.7 version of the JDK? Guess, then I'll run the Java.exe in the JDK1.8. As expected, the JRE under the same directory is now renamed, forcing it to read the registry. The registry is now in the 1.8 version of the registry with an error, yes, because there is no option for the 1.8 version at all"Why not I don't know, the JDK swap to change I have forgotten, as to can add myself I do not understand, at present I do not need; and I don't know anything about the Windows registry."。 So if we change the CurrentVersion version to 1.7, then we can be sure.Java.exe Version "The book explains the principle of this packaging, not explained here."to decide. Then we put the 1.7 version of the registry, modified to, and then try Java-version. Not at this point, version must be the result of 1.8.the above modifications are for the purposes of the experiment, as to what will happen if the 1.7 version of Java.exe is used, the registry or the JRE in the same directory is version 1.8. I don't know, I don't really want to know at the moment. Hopefully, after studying the mechanics of Java, we can understand. why not go through the registry, directly modify the JRE file under the JDK there is no such situation, I do not know.
Anyway, the above is an experiment, we do not need in the actual development of the JRE version in exchange for, as long as we know what version of the JRE,JDK, then if the library or the like, or appear above my practice when the problem will not confused, at least have some understanding.
additionalIn the past I have heard about the role of System32, probably from this file add to find the corresponding command corresponding executable file. At the very beginning of my system, System32 was present in the Java.exe file. But I deleted it. So this time all the tests are irrelevant to it. I was curious about how Java.exe found the JRE in System32, and the initial guess was the registry, so I copied the java.exe that came with the JDK1.7. The result of removing the path from the previous java.exe is that I initially wanted to conclude that the lookup in System32 Java.exe was done directly through the registry. But all of a sudden, java.exe is just a wrapper class that really points to a main function in tools. Then I decided to restore the JRE in the JDK1.7. If the JDK1.7 in the use of the JRE, then it should be 1.7 version, but the results are still appear to be implemented through the registry, or the Java.exe implementation of the method is still found through the relative path to find, no find to look for the registry.
wrote here found that Javac.exe is the packaging class, Java.exe not explicitly stated, because Javac.exe is a main function that points to the tool and may be judged by a relative path. What happens if I copy javac.exe copies to System32?Could not succeed, but the missing file is indicated as Jli.dll. When I decided to jump to conclusions"Java.exe can function properly, stating that Java.exe should not be a wrapper class." But later I found that I added the Java installation directory to path, and moved Javac.exe out to another place to run the result as "could not find main". The suspicion is not that javac.exe is caused by the wrapper class. In order to solve this problem, I want to move Javac.exe and Jli.dll together into the system32 to see if the wrong can become could not find main. "The JAVAC environment variable is already set" when I move Javac.exe into System32, I have reported could not find Main's fault, So said Jli.dll search should be through path, find a bit, the corresponding JDK has two jli.dll. According to the logic of the book, Javac.exe is resolved by the JRE, which is the JRE under the installation directory, so the conjecture will be the Jli.dll under the JRE. The name of the DLL under the JRE is renamed, no impact is found, and the DLL is not found in the same directory. And the DLL under the JRE is restored, and the DLL cannot be found. Therefore, the DLLs used here are DLLs in the same directory. But if it is based on the same directory to judge unscientific, because when the java.exe copy to System32, the execution of the time can not be the same directory to get the DLL. So it is possible to find all paths in path, and according to this conjecture, change path to the path of the JRE. installation directory \bin\jli.dll renamed to \bin\jli_1.dll But there is no jli.dll to find, just can't find the main.
Conclusion
1. Jli.dll Look for it through the path directory.
2. Move Javac.exe to System32 the main method is not found (requires inventory in), but Java.exe does not exist. Description Java.exe is not a wrapper class, and Javac.exe is a wrapper class
Java and JRE "Java Deep Adventures note"
