1

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?

Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
Nitin Chhajer
  • 2,299
  • 1
  • 24
  • 35
  • I'd draw a single conclusion from all of this. Sun (Now Oracle's) story for using the JRE in applications is lacking. If only for one thing, Microsoft got .NET's installation and referencing correct compared to the myriad of problems with distributing the JRE and using it. – Andrew T Finnell Apr 17 '12 at 22:21
  • 1
    *"I was working on packaging my software"* Use [Java Web Start](http://stackoverflow.com/tags/java-web-start/info) (if you intend to complete this task before April 2013). As to the JRE, use the `deployJava.js` linked from the JWS info. page. – Andrew Thompson Apr 18 '12 at 04:26
  • @AndrewThompson Thanks, I am packaging an offline application. But this will be helpful when I do move it as online distribution. Probably for a demo version. – Nitin Chhajer Apr 18 '12 at 12:42
  • *"I am packaging an offline application."* There are probably more machines that run desktop Java with net connections but no drives (e.g. Netbooks), than there are that have drives with no net connection. JWS also gets around the cost of burning (printing, packaging, delivering) a CD/DVD or flash drive. I think you should reconsider the situation of the typical end-user. Note though (in case I misunderstand you), that JWS has an `offline-allowed` flag. It means that *the user can run the program even when not connected to the net.* – Andrew Thompson Apr 18 '12 at 12:48

4 Answers4

2

can I copy this folder into some other machine(with same processor 32bit or 64bit) to make JRE work

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 ftype and assoc commands. They can do that e.g. from within a batch file or installer.

If that is so then what are the environment variables that are needed to be set?

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).

1

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.

Update

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.

Andrew T Finnell
  • 13,417
  • 3
  • 33
  • 49
  • Sorry, this isn't right at all. _Many_ applications rely on _CLASSPATH_, _JAVA_HOME_, and some of the older environment variables pointing to the current expected JRE. It's true that _Java_ will work without them if you're just describing the binary, but it'll become deeply confused, as will applications that rely on it, if these variables aren't in place. – MrGomez Apr 17 '12 at 21:30
  • @MrGomez Not a single commercial application I've worked on, or used has relied on JAVA_HOME or CLASSPATH being set, as relying on those is one of the quickest ways to ensure your application won't work. Sure, a lot of Java tools and SDK's use those, but I dont know of many applications that do. Even Eclipse does not consult or use JAVA_HOME or CLASSPATH. – Andrew T Finnell Apr 17 '12 at 22:00
  • And yet, many Apache applications appear to do so (including, for example, Hadoop). It's worth keeping a note here on those, precisely for the reason that they're corner cases that are, unfortunately, quite common. – MrGomez Apr 17 '12 at 22:10
  • 1
    @MrGomez I can't say I'd reference Apache applications as a guide on how to run applications. Also, if this is a commercial application I cannot imagine paying customers would be happy with a prompt saying JAVA_HOME is not set and the application exiting which is what Hadoop does. It also sets CLASSPATH to a single value at the start of it's config as to not pick up other JAR's listed in the existing CLASSPATH. Anyone that has done XML processing can talk about horror stories of mixed xerces JAR files. – Andrew T Finnell Apr 17 '12 at 22:19
  • I don't disagree. It's functionally identical to the horror stories surrounding _LD_LIBRARY_PATH_: it's not good practice, but you just know _someone_ will do it. Bringing it up and outright refuting it as bad practice is, often, the best medicine. :) – MrGomez Apr 17 '12 at 22:22
0

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. However, 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 still need to set the environment variables manually. Only a strict subset of these are required for most needs (see the other answers), but it's the corner cases that are most interesting when bounding this class of problem.

Community
  • 1
  • 1
MrGomez
  • 23,788
  • 45
  • 72
  • You realize that the Java installer does not change PATH, JAVA_HOME or CLASSPATH or set them if they are missing. Try it and see for yourself. In fact, there is a SO question about why it does not do this: http://stackoverflow.com/questions/560797/why-doesnt-the-java-sdk-installer-set-java-home – Andrew T Finnell Apr 17 '12 at 22:03
  • @AndrewFinnell Sorry, you are indeed correct. I had confused these with third party packagings of the JRE (for example, the packagings for CentOS), which do indeed set and maintain these. The vanilla packagings do not. I will update my answer. – MrGomez Apr 17 '12 at 22:13
0

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 documentation) 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.

Carlos Tasada
  • 4,438
  • 1
  • 23
  • 26