java程序转化成exe(国外英语资料).docVIP

java程序转化成exe(国外英语资料) Java development process, when publishing, the total consideration is how to install JRE on the users machine. There are many issues to consider: whether the user has the ability to install JRE alone, whether the existing JRE is consistent with the version we need, whether version problems occur, and so on. There are fewer issues to consider with.NET. Now,.NET CLR seems to have become very popular, to see a lot of D version of Win XP will install the latest.NET CLR, and it seems that the installation interface is better than JRE friends. A thorough solution to the problem of installing JRE is to let our applications carry JRE on their own! In this way, our programs, like traditional Win32 applications, can be executed by double clicking, without having the JRE on the machine, and what version of JRE is, anyway, I have my own! To do so is actually very easy. Wang Sen explains the relationship between JDK, JRE, and JVM in the first chapter of his Java deep adventures (strongly recommended, the book is short and accurate). Explains what happened when we implemented java.exe. The java.exe, in accordance with a set of logic can be used to find the JRE, first look the directory where there is no JRE (according to Wang Sen say not exactly, I dont have a JDK complete source code, this Wucongkaozheng); secondly find the parent directory has no JRE; the last is query Windows the registry. Usually, we can execute java.exe on any of the directories that have been installed on the JRE machine. Because it was copied to the windows directory of system32 when it was installed, and the latter would be in the path environment variable anyway. The java.exe will eventually access the registry to determine where the real JRE is located. If we require every application to bring JRE, we must not go that way. But in the second logical case, java.exe looks for JRE in its parent directory, and the solution is in this one. Suppose our application puts a package, called M