Community

The situation:

1. I have two (2) jdk's installed on my Win2K system: 1.1.8 and 1.2.2, (I'm forced to work with legacy code that's not compatible with newer versions.) I installed and worked with 1.1.8 first.

2. They are installed in C:\jdk1.1.8\ and C:\jdk1.2.2\

3. My PATH variable points to the C:\jdk1.2.2\bin\ directory, and it's the first entry in the list of directories.

4. When I attempt to use the preset jdk commands in TextPad 4.5.0, (Compile Java, Run Java Application, and Run Java Applet,) somehow TextPad insists on using the jdk 1.1.8 executables. I'm sure of this because it fails to compile Swing code that's available in 1.2.2, but not 1.1.8.

5. When I manually add the executables using the Add-->DOS Command..., it works fine, using the 1.2.2 jdk! I don't even need to explicitly write out the paths to the \bin\ directory, just call the .exe directly since it's in the System PATH. I even added the DOS Command: "java -version", and, true to form, saying that the version is 1.2.2.

What's happening here? Is there some sort of record that TextPad keeps of the location of the jdk? Is it looking there for the jdk executables? This is very confusing.

I've got the same problem.

I have 2 Java virtual machines on my system (Windows XP Pro). They are: 1.3.1_03, and 1.4.0. I cannot get TextPad to use Java 1.4.0. I looked at your FAQ and did both of the recommended actions (create a CurrentVersion registry key, set the Path variable), but it still uses 1.3.1_03 instead of 1.4.0.

By the way, I had to CREATE the CurrentVersion registry key, it wasn't there in the registry when I first looked.

Actually, I've managed to solve this problem, so if anyone else is facing a similar issue, this might be useful:

1. TextPad IS NOT, in fact recording the location of the jdk. THE JDK IS! If you go to the System registry, and navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\

Under it should be a key labelled CurrentVersion, with a value that should be either 1.1, 1.2, 1.3, 1.4, etc...

This is the "official" version of java on your system. This value MUST correspond to the name of a key UNDERNEATH the current key. For example:

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\CurrentVersion=1.2

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.2\

That second key, at that point, will ALSO have a name-value pair, named JavaHome, which identifies the location of the jdk, and commensurately, the bin\ directory to search out the .exe's.

So my problem was that my CurrentVersion was pointing to 1.1; Changing it ot 1.2 solved the issue.

After having the same problem also since I have 1.3.1_02 and 1.4 JDK's, I added environment variable CLASSPATH and gave it the value of . (that's a dot). So if you have multiple entries in your CLASSPATH, mine looks like the following:
.;C:\jakarta-tomcat-4.0.4\bin; So dot is separated by a semi-colon in this case; otherwise it's just a dot.

But rather than messing with the CLASSPATH env var, I'm going to deploy scripts from Jim G who replied to this question prior.

My problem was solved by doing the registry key thing described by Garrett Johnson.