java.jdk and java.jre system properties

[Roedy Green]

The lack of a java.jdk and java.jre system property is now officially
considered a bug, with a number 6304516.

you can even vote for it at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6304516.


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Chris Berg]

... which reminds me: in Windows, when I open a Command prompt and type

C:\myhomedir>java

then it finds the JRE runtime, even though "C:\Program
files\Java\jre1.5.0_03\bin" is not in the path=.. environment variable.
How does i find it? And how do I change it if I have more than one VM
installed?

Chris

 

[Roland]

... which reminds me: in Windows, when I open a Command prompt and type

C:\myhomedir>java

then it finds the JRE runtime, even though "C:\Program
files\Java\jre1.5.0_03\bin" is not in the path=.. environment variable.
How does i find it? And how do I change it if I have more than one VM
installed?

Chris

There's a java.exe in the Windows system directory (C:\WINNT\system32 on
my Win2000 system). This directory normally *is* included in the PATH
environment variable. In general this java.exe is exactly the same as
the java.exe in the JRE\bin folder (it's put there by the Java
installer, like some others: javaw.exe, javaws.exe, jpicpl32.cpl).

When the java.exe starts, it tries to establish the location of the
runtime environment. The C source of this launcher is available in the
src.zip (if you have the SDK installed): java_md.c (_md stands for
"machine dependent", in this case it's for the Windows OS).

Looking at the 1.5.0_04 source, java.exe first tries to find the path to
JRE based on .exe's location (checking if ..\bin\java.dll or
...\jre\bin\java.dll exist), and then --if it fails-- on some Windows
registry entries.

When the java.exe of a JRE is invoked, for example C:\Program
Files\Java\jre1.5.0\bin\java.exe, it will find java.dll in the same
directory (..\bin\java.dll) and JRE home is established as C:\Program
Files\Java\jre1.5.0.
When the java.exe of a *JDK* is invoked, e.g. C:\Program
Files\Java\jdk1.5.0\bin\java.exe, java.dll is not located in the same
directory, but in C:\Program Files\Java\jdk1.5.0\jre\bin, and therefore
JRE home is established as C:\Program Files\Java\jdk1.5.0\jre.

Now, when the java.exe in the windows system directory is invoked, e.g.
C:\WINNT\system32\java.exe, (normally) there's neither a C:\WINNT\bin\
nor a C:\WINNT\jre\bin\ folder (and no java.dll), and the java.exe
launcher uses the second way --examining some Windows registry entries--
to establish the location of the runtime environment. The primary entry
that it checks is HKEY_LOCAL_MACHINE\Software\JavaSoft\Java Runtime
Environment\CurrentVersion. If that does not match the value that is
hardcoded in java.exe (this hardcoded value will of course match the
installed JRE/JDK version), it will generate an error message like the
following:

Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.5', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java 2 Runtime Environment.


So when you ask how to change the version of the java launcher that is
installed in the windows system directory, I would say don't (unless you
need to repair it). When you need to invoke a specific version, use the
full path to the JRE\bin\java.exe (or javaw.exe). The launcher will find
the correct runtime environment automagically.
--
Regards,

Roland de Ruiter
` ___ ___
`/__/ w_/ /__/
/ \ /_/ / \

 

[Roedy Green]

then it finds the JRE runtime, even though "C:\Program
files\Java\jre1.5.0_03\bin" is not in the path=.. environment variable.
How does i find it? And how do I change it if I have more than one VM
installed?

I discovered two ways of accomplishing that.

One is to put a dummy java.exe in C:\windowsNT which is on the path
which then looks in the registry to find out where the real java.exe
is. Actually nowadays, it is the same code for dummy and real.

The second is to put an entry in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\firefox.exe(default)
=
E:\Program Files\Firefox\firefox.exe

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\firefox.exe(path)
=
E:\Program Files\Firefox\

This lets you put something on the path and define its starting
directory without cluttering up the path.


IRRC Java.exe uses the first method and javaws.exe uses the second.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Chris Berg]

How extremely complicated that sounds! I _may_ try to fiddle with it
on my own PC but _never_ om somebody else's, where my programs will
eventually end up.

The reason I am interested in this is that I have a java app that is
actually a server, and it runs best under JDK (not JRE), with the
-server flag set, which would create an error message on JRE. JRE
seems to be the default vm. I use JBuilder to create an .exe file from
the jar (I beleive this makes it a bit more difficult to hack my
bytecode), but the 'java.exe' invokation gets embedded in the .exe.

But from what you say, I would think that yet another solution could
be to add "C:\Program Files\Java\jdk1.5.0_03\bin" to the beginning of
the path=.. env. variable. This way it would find the right one. And
that would not be so difficult to do while installing on a foreign
machine. Or?

Chris

 

[J Lafortune]

The reel solution

This happen if you try to install an too old version of java.

To resolve this, symply delete the old java.exe or other java related .exe in c:\windows\system32 or c:\windows\system
and reinstall the latest java version.