Difference between JAVA_OPTS and JAVA_TOOL_OPTIONS? - java

When should each of these environment variables be used?

JAVA_TOOL_OPTIONS is read by some JDK tools, but has limited applicability.
JAVA_OPTS is a convention used by Apache Tomcat and some other apps, but is not
read directly by any JDK tools published by Sun/Oracle, AFAIK.
From:
https://forums.oracle.com/forums/thread.jspa?messageID=6438415
JAVA_OPTS is not an environment variable that the java executable will
recognize on it's own. Instead, various scripts which wrap the start
up of java will often use an environment variable named JAVA_OPTS to
configure the java executable (for example, the tomcat startup script
does this).

see "what is" doc and "tool options" doc
Basically, the JAVA_TOOL_OPTIONS is intended for use by development tools, monitoring tools and the like whereas JAVA_OPTS is used for running 'general' Java programs, I think people tend to mix and match somewhat (from what Google has shown me example wise).

Related

Do we need to set Windows environment variables for Java updates anymore?

I've been setting Windows environment variables (like JAVA_HOME) every time I installed a Java update. (As per Environment variables for java installation).
However, I've recently noticed that Java updates add C:\ProgramData\Oracle\Java\javapath; to the System Path (not the User Path). I removed JAVA_HOME, etc from my User Path, and java -version seems to work from any directory.
Does that mean that it is not necessary to do that simple but annoying task with each Java update?
That depends on what you are trying to do.
Generally, you don't need JAVA_HOME to run a Java app. Adding the location of the Java binaries to the PATH is sufficient for Windows to find and execute them.
However, e.g. a lot of application servers like Tomcat and build tools like Gradle will use JAVA_HOME to determine the location of your Java installation.
Java itself does not use JAVA_HOME. Some third-party things like IDEs and Tomcat do. I've never set it as an environment variable in 20 years.
Personally, I don't even have JAVA_HOME set and I've been developing at this company for 6 years now (and other companies for 10+ years). To me, it tends to get in the way. The last install sets the windows path which generally isn't what my IDE's, Tomcat, JBoss or SOAP-UI support so I just edit all their startup files to choose/set the JAVA_HOME they work with.

What environment variables affect the 'java' binary?

Most unix commands whose operation changes based on values of environment variables have a section "ENVIRONMENT VARIABLES" in their man page. No such luck for the java binary (Sun/Oracle Java 6), though I'm fairly certain that things like CLASSPATH and perhaps JVM_OPTS have an effect.
Can anyone point me to a list of environment variables that affect the 'java' binary?
I don't think there are that many, but it will depend on what implementation (oracle vs ibm).
IBM's JDK has a list here: http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/topic/com.ibm.java.doc.diagnostics.50/diag/appendixes/env_var/env_jvm.html
The oracle JDK has, at the very least, CLASSPATH, JAVA_HOME and JRE_HOME. Although in the man page for "java", the only environment variable it mentions is CLASSPATH.
Other tools like ant or tomcat may look for JVM_OPTS, and JBoss uses JAVA_OPTS.
Setting JAVA_HOME to the installation directory and adding $JAVA_HOME/bin to the PATH sould be enough, if you don't have to configure build systems like maven or ant.
CLASSPATH is required on most start scripts to contain the location of supporting libraries (.jar) or third-party stuff.
JAVA_OPTS usualy contains parameters for setting heap-space, debug agent and things like that.
AFAIK java itself does not depend on environment settings, rather start scripts, init services and anything build around.
Thus you won't find a single list of all environment variables related to java (software-products).
There is also _JAVA_OPTIONS, mentioned here, which works for all JVM invocations, including applets and Webstart.
Incomplete answer to my own question:
Oracle has a list for Java 8 of env variables to include when reporting a bug. Not really documentation, and no guarantee it's complete, but it is highly suggestive:
JAVA_HOME
JRE_HOME
JAVA_TOOL_OPTIONS
_JAVA_OPTIONS
CLASSPATH
JAVA_COMPILER
There is specific documentation on JAVA_HOME and JAVA_TOOL_OPTIONS

Can you check whether your OS and java runtime are 32-bit or 64-bit from within your program?

I was told there is a System Environment Property File i could check, however, it hasn't yielded any definite results so far.
Basically I need to see what version of the OS and Java i'm running so I can copy the correct DLLs to the run directory. As always, a better solution is appreciated.
You can check JRE version checkin os.arch property of System class
http://mark.koli.ch/2009/10/javas-osarch-system-property-is-the-bitness-of-the-jre-not-the-operating-system.html
JNLP - Java Web Start - allows for specifying DLL's and shared libraries per architecture. This allows you to do centralized distribution with a local icon for the users to click.

Can I have applications using Java 1.4.2_12 and Java 1.5 on the same windows server

I have a couple of applications running on Java 1.4.2_12 and now need to add an new application that uses Java 1.5. Can I have both java versions on a windows server?
Yes. You just need to make sure that each has the correct version of Java/the JRE on its CLASSPATH, PATH and JAVA_HOME environment variables.
Yes: actually JDK or JRE can be just "copied" wherever you want, not "installed" (avoiding putting anything in c:\Windows\System32)
I would also recommend not using global environment variables.
That way, your applications depend entirely on local settings (local to the application), and not on external Java installation side-effects
Are you sure you have to have the Java 1.4.2_12 apps run using that specific Java VM? Most apps should run fine on the newer VMs, so you might be able to simply have them all use 1.5.
If you do need to use the specific VM versions then you can do what other posters have suggested.
YES. See above. Of course, running two VMs (of any version) takes twice the RAM.
I could suggest you to use Java WebStart, which allow you specific the target J2SE version in the JNLP file. Or; always execute the right version "java.exe" under "Program Files" by absolute path.
You don't have to set CLASSPATH for JRE (and should not in modern JRE). JRE have it own bootclasspath automatically. CLASSPATH is used by your application.
Usually you won't have to set the JAVA_HOME unless your appliaction is looking for resources from JDK\lib\ (e.g. tools.jar which contains compiler)
But I am not sure what's your problem.
Are you running client application(swing)? Two Java processes to provide services? or two application sharing same Java application server?

java web start JAVA_HOME

I have an application that starts a Swing gui using java web start. The user has 4 versions of java 1.6 installed (1.6.0.3, 1.6.0.5, 1.6.0.7. 1.6.0.11)
Webstart is selecting java version 1.6.0.11 but JAVA_HOME is set to java version 1.6.0.3. Could this cause any potential problems for webstart?
rich
In this thread, it is mentioned a Java Web Start application check the version of an available JRE in this path:
C:\Documents and Settings\[User]\Application Data\Sun\Java\Deployment\deployment.properties
(for Windows XP)
C:\Users\[User]\AppData\LocalLow\Sun\Java\Deployment\deployment.properties
(for Windows Vista)
In it, lines like:
deployment.javaws.jre.0.path=C\:\\Program Files\\Java\\jre6\\bin\\javaw.exe
deployment.javaws.jre.0.product=1.6.0_11
are found.
I believe the JWS will start with those settings, not the ones from a JAVA_HOME variable, which should not be a problem.
As detailed here,
The deployment.properties file is used for storing and retrieving deployment configuration properties in the Java Control Panel. They are also used for customizing runtime behavior for both Java Plug-in and Java Web Start.
There is always a User-Level deployment.properties file. Its location, which is non-configurable, is described below. There may also be an (optional) System-Level deployment.properties file.
Take a look inside the jave web start script. They might have their own JRE or JDK path inside it. The user might be even using a version that is not listed on the list above. This is usually done to easy installation on the end-user.
Hope you find the solution.

Categories