I was working on packaging my software and wondering how does the installation of JRE work. Does it simply copy the binaries on the local system and set the classpath accordingly or any other steps are done by the installer?
For windows the JRE binaries are stored in
C:\Program Files\Java\jre7 can I copy this folder into some other machine(with same processor 32bit or 64bit) to make JRE work. If that is so then what are the environment variables that are needed to be set?
<em>can I copy this folder into some other machine(with same processor 32bit or 64bit) to make JRE work</em></blockquote>
Yes, no problem. Unless you also want to register the .jar extension so that you can double-click them.
In that case check out the
assoc commands. They can do that e.g. from within a batch file or installer.
<em>If that is so then what are the environment variables that are needed to be set?</em></blockquote>
No need to set any environment variable.
Just make sure you qualify the path to javaw.exe (or java.exe) correctly when starting your application (e.g. through a batch file).Answer2:
You can put the whole JRE in a sub directory and just reference java.exe based on the sub directory. This is done quite frequently by other products.
You don't need to set any Environmental variables.
If this is a commercial application that is not a JRE toolkit (i.e. something like Maven or Ant) do not rely on the global Environmental variables JAVA_HOME, PATH or CLASSPATH to be set. If you want to create a batch file that when ran, automatically sets that in the context of your application, that'll work fine. But do not rely on them to be set in the System.
All it will take is for someone to change these to use some version of 1.7, or 1.8 beta, or really any sub-version of the JRE to break your application and then you'll get Customer Support calls about your application breaking, when really what they did was change their JAVA_HOME to something absurd because they misread the Ant documentation.
If you are providing a toolset that works in conjunction with the JDK, such as Ant or Maven, you'll probably want to use whatever JRE/JDK they have installed as that is the point of your tools.Answer3:
If you don't specify any argument, the JRE installer install the needed binary and executable files, but also creates the needed windows registry entries to configure your JRE installation.
You can also install using the "-static" option (see the JRE installer <a href="http://www.oracle.com/technetwork/java/javase/silent-136552.html" rel="nofollow">documentation</a>) in which case doesn't do anything else but copying the files to the specified path.
Then you'll need your environment variables manually. For the command-line, the most common ones are: PATH, JAVA_HOME and CLASSPATH.Answer4:
The short version is, it depends. But for the most part, the constraints of binary compatibility and library paths are sufficient to get the JRE working in shared environments (as we do in some of our machines at work).
Because Java provides a virtual machine to handle requests, and because it can do so fairly independently of some of the other bells and whistles owned by the system, your intuition about its classpath and binary disposition holds true. <em>However</em>, you may run into problems with libraries that expect a well-formed and system-specific set of paths and libraries, which are afforded in some of the OS packages provided by third-party libraries.
In short: if you have the option to, install Java from its installer, because this will guarantee all classpath details, all libraries, all logging facilities, and all system-specific errata are accounted for, though as Andrew Finnell points out, you'll <a href="https://stackoverflow.com/questions/560797/why-doesnt-the-java-sdk-installer-set-java-home" rel="nofollow">still need to set the environment variables manually</a>. Only a strict subset of these are <em>required</em> for most needs (see the other answers), but it's the corner cases that are most interesting when bounding this class of problem.