This project outline is not like the artificial tidy problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the define the end point, or a series of ever more difficult versions of this project, and research the information yourself to solve them.
Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many other projects of my own.
Though I am a programmer, I don’t do people’s homework for them. That just robs them of an education.
You have my full permission to implement this project in any way you please and to keep all the profits from your endeavor.
The three versions of the Java Plug-In interfere with each other. In theory you can have only one of them installed at a time. However, you need all three for testing. The simplest version of program would effectively hide two out of the three at any one time, by fiddling with registry entries.
Other JVMs interfere with each other since they may each set the classpath or path a different way. In a similar way, you want to hide all but one of them so they cannot interfere with each other.
For more of a challenge, allow each App to provide a properties file that lists the JVMs it prefers to run under, and the class files it needs pre-installed and the URLs where you can get them if necessary. Your job is to set up its preferred environment, and hide the others. Unfortunately, this limits you to running one JVM at a time. See installing Java for more details.
One extra wrinkle is to check on the web for the latest properties file, so that you know if you must update the App itself as well as any auxiliary files.
You need to install various versions of the Plug-in, ensure they work, and study the registry to see what changes the installer makes. Norton Utilities for Windows used to include a utility for noticing registry changes. I’m not sure if they still ship it. You could also detect registry changes by regedit-exporting the registry to text format and using a standard diff utility.
Your program has to effect these same changes. Java can’t twiddle the registry directly. You must use a native class written in C or C++ that uses the Windows registry fiddling API calls. InstallShield for Java has facilities to fiddle the registry. That would be a way to kludge it.
Look at these entries in the registry:
My computer\HKEY_CURRENT_USER\Software\JavaSoft\Java Plug-In
My computer\HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Development Kit
My computer\HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Runtime Environment
My computer\HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Plug-In
The other thing this utility would do is back up the registry and restore it or
recreate it from first principles if it ever becomes damaged, a frequent event.
You also want to switch environment variables such as classpath and JIKESPATH.
For a rough and ready manager you could use regedit that has the ability export and import parts of the registry. You take snapshots, and just switch between snapshots.
| You can get the freshest copy of this page from: | or possibly from your local J: drive (Java virtual drive/mindprod.com website mirror) | |
| http://mindprod.com/project/jvmmanager.html | J:\mindprod\project\jvmmanager.html | |
![]() | ||
| Canadian Mind Products | ||
| mindprod.com IP:[65.110.21.43] | ||
| view Blog | Your face IP:[38.107.191.104] | |
| Feedback | You are visitor number 8,416. | |