Let the Java program bring its own JRE

Program   Use Java Development Program, the issue always need to consider is how to install the JRE on the user's machine. There are a lot of questions to consider: whether the user has the ability to install the JRE on their own, whether the user already has a JRE and the version we need is inconsistent, if there is a version problem, and so on. Use. NET, there are fewer issues to consider. Now that the. NET CLR seems to be very popular, the optimistic version of Win XP will install the latest. NET CLR on its own, and it seems to have a more user-friendly installation interface than the JRE. The solution to the problem of installing the JRE is to get our application to carry the jre! In this way, our program is like a traditional Win32 application, double-click can be executed, regardless of whether there is a JRE on the machine, what version of the JRE, no matter what, I have my own! To do that, it's actually very easy. Sen Wang's first chapter in his "Java Depth Adventures" (a strong recommendation for this book, with fewer content) explains the relationship between JDK,JRE,JVM. Explain what happened when we performed the Java.exe. which mentions that Java.exe in accordance with a set of logic to find the JRE can be used, first of all find their own directory there is no JRE (according to Sen Wang said this is not accurate, I do not have all the JDK source code, this can not be verified); second, find your own parent directory there is no JRE; Normally we can perform java.exe on any directory on the machine where the JRE is installed. Because it was copied to the Windows system32 directory at installation time, the latter would be in the PATH environment variable anyway. The Java.exe will eventually have access to the registry to determine the location of the real JRE. If we require each application to bring its own JRE, this path must not be taken. However, the second rule of logic says that Java.exe will look for the JRE in its parent directory, and the solution is in this section. Let's say our app is packed, called Myapp.jar, and placed in the MyApp directory. We can execute Java–jar Myapp.jar to run our program under the MYAPP directory. We are installing JRE 1.5, under C:\Program files\java\jre1.5.0. Now, we just need to simply move the jre1.5.0 directory to the MyApp directory, and change an easy to write name, such as the JRE. Now, our application is like this:myapp       myapp.jar       Jre   &The entire contents of the nbsp;           Jre1.5.0 directory are Java.exe in the bin directory under the JRE directory. According to the second logic, Java.exe looks for the JRE in its parent directory, and the experiment confirms that it looks for the Lib directory, and Lib is in the JRE directory. So Java.exe will determine where the JRE is and then execute the Java program normally, without going through whether we have the JRE installed, or if there are any registry entries in the registry. Try to enter the MYAPP directory under the command line, assuming it is in C, point the path to the Jre:set Path=c:\myapp\jre\bin under MYAPP and run: Java–verbose–jar Myapp.jar plus the verbose parameter to make sure we did use this set of JRE that was moved out of the home. The program can run, and in the first few lines of the output from the command line, you can see: [Opened c:\myapp\jre\lib\rt.jar][opened c:\myapp\jre\lib\jsse.jar][opened C:\MyApp\jre\ lib\jce.jar][opened C:\MyApp\jre\lib\charsets.jar] So the program reads really its private JRE. At this point, we seem to have completed the task. But now our private JRE is still imperfect, and the downside is too great. JRE 1.5 is close to 70MB, and as our private JRE, a lot of content can be discarded. JRE directory under the license can not, the bin under the implementation of the file only need to retain Java.exe or javaw.exe,lib, as long as the retention of rt,jsse,jce,charsets a few libraries can be. In addition to the i386 and Zi two subdirectories, the rest of the subdirectories are not available. Zi only need to keep a subdirectory of its own area and some of the files under it. LIB is reserved for property files other than libraries. To clean up this, the JRE is still close to 50MB. You can also continue to clean up a few library files do not need content, which requires careful collation, will be very time-consuming. It's best to write an automated tool to help us organize them. The Java-written media player from Sun's JMF comes with a JRE and only a few MB. After cleanup, we need to run our application several times to make sure our JRE is not missing anything. If we want to have a program that launches our application directly, it will take some effort. The easiest way to do this is to make a shortcut, but the shortcut sideType of path cannot be relative and inconvenient for us to install. I think of the plan is to use the WIN32 program packaging. Write a Win32 applet under vs.net: int PASCAL WinMain (hinstance hinstance,    hinstance   LPSTR lpszcmdline,    int ncmdshow) {    startupinfo si;    Process_information pi;     ZeroMemory (&si, sizeof (SI));    si.cb = sizeof (si );    ZeroMemory (&pi, sizeof (PI));    //Start the child process.     if (! CreateProcess ("Jre\\bin\\javaw.exe",//executing program name                          "Jre\\bin\\javaw.exe-jar Myapp.jar",// Executive program with parameters             null,             //Process handle not inheritable.             NULl,            //Thread handle not inheritable.             false,            //Set handle inheritance to FALSE.             0,                //No creation flags.             null,             //Use Parent's environment block.             null,             //Use parent ' s starting directory.             &si,              //Pointer to STARTupinfo structure.            &pi)              //Pointer to process_information structure.    )     {            errorexit (" CreateProcess failed. ");    }    //wait until child process exits.    WaitForSingleObject ( Pi.hprocess, INFINITE);    //close process and thread handles.     CloseHandle (pi.hprocess);    CloseHandle (Pi.hthread); Basically follow the example in the MSDN documentation. To compile it into an EXE file, our task is complete. Double-click this EXE file, our program started, looks like the traditional Win32 program is no different, the JRE is completely hidden in the bottom. P.S. After using this scheme, I used wise installation system to make the installer and found a very strange problem, after the installation, the installer seems to be running a program called GLJ what, suffix is tmp, also need the JVM, The result is an error JVM.DLL can't find it. Installation is always unsuccessful. I've already banned ocx/dll/exe. Self-registration and uninstall support, why not? Does anyone know why?