Making it easier for Java 2SE/TextPad to work together....

[frbcoindude]

okay, okay! Enough already!

Sun seems to be putting out new releases of the java 2 SE platform pretty regularly. I have been through this, and hate it eaach time I have to do it!

1) Installed JDK1.3.1, installed TextPad 4.5, all okay.

2) Installed JDK1.4.0, Textpad can't find javac.exe, (folder names changed). Uninstalled TextPad, reinstalled, all okay.

3) Upgraded to Textpad 4.6, lots of problems, but got there.

4) Installed JDK1.4.1, Textpad can't find javac.exe, (folder names changed). Uninstalled TextPad, reinstalled, all okay.

NOW, there is a new Java2SE out and I need it for a new project.

Short and sweet....

How can I update TextPad to see the new folder names after I have
installed the new version and NOT have to re-install my version of
TextPad?!??!?!?

Is there a macro? Java code? Anything?

HELP!

Bob

[Guest]

You are not alone when it comes to using diffrent JDK's...
Did you see this thread?
http://textpad.com/forum/viewtopic.php? ... istry+java
Anyway, sure hope this will be in the next MINOR release of TP
(ie. not a selling point for version 5, same goes for folding, anyone
seen http://www.jedit.org )
--
sr

[Garrett]

From what I can tell, TextPad, when it is installed, locates the current JDK and somehow assigns it's java commands to those executables. In order to update TextPad's assignments, you need to remove TextPad and then reinstall, at which point it will bind to the new JDK.

I'm not precisely sure how it determines which JDK to bind to when it installs itself, but I suspect that it locates the current version of java using java's own registry entries, usually at or around:

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft

It probably looks for the most recent version in these keys at binds to it, though I've no idea where it stores such information. It's not in the registry, so I can only assume it's somewhere in the .ini files. The only other place it could be is compiled INTO the .exe or .dll files, but I rather doubt that: The installer doesn't appear to be doing compilation on the fly.

Point is, the best way to handle this, short of reinstalling TextPad, is to edit the registry to reflect the new locations of the jdk.

[frbcoindude]

Well, that sounds like what is done to locate the JDK. Why can't there just be a menu item for "Refresh" | "SDK Location", or make it part of the Preferences?

[Garrett]

Well, probably because that's not the right way to handle it. This is an exceprt from an email I received from TextPad tech support:

****************************************

TextPad determines which javac.exe it should use, by looking at the value of
the current version in the Registry.

The solution should be to change the Registry key to the correct file path
for the current version of the JDK.

Please expand the Register as in the following example:

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.4

Clicking on Java Development Kit reveals the current version value, 1.4 in
the example above.
Clicking on the plus sign next to Java Development Kit reveals any other
versions of the JDK.
Clicking on the key of the Current version, you should see "JavaHome" in the
right hand pane. Right click on JavaHome and select "Modify". Type in the
correct path for the Current version.

****************************************

So far as I can tell, this means that when confronted with the command: java.exe, javac.exe, or appletviewer.exe, TextPad looks in:

HKLM\SOFTWARE\JavaSoft\Java Development Kit\

and finds the name-value pair ID'ed by: CurrentVersion

With that version, it then goes to the appropriate key. In my machine:
CurrentVersion = "1.4" Therefore it would go to:

HKLM\SOFTWARE\JavaSoft\Java Development Kit\1.4\

and then fing the name-value pair ID'ed by: JavaHome

With that information, it then goes to that directory and descends to the \bin\ directory to find the executables. In my machine:
JavaHome = "C:\j2sdk1.4.1_01" Therefore it would go to:

C:\j2sdk1.4.1_01\bin\java.exe
C:\j2sdk1.4.1_01\bin\javac.exe
C:\j2sdk1.4.1_01\bin\appletviewer.exe

If you really think your install is not correct, and you want to check, you should go to:

HKLM\SOFTWARE\JavaSoft\

and verify that the JDK install went properly. From what I can tell, the faut lies not with TextPad, but with Sun. I don't think they always handle the JDK install perfectly.

[jeffy]

I actually have both 1.3.1 and 1.4 JDKs installed. I've been trying to upgrade my code for a couple years now, from 1.3.1 to 1.4. It's actually pretty easy to do (only change throughout all 200 code files was how StringBuffers did indexOf . Not to mention the change wasn't even necessary).

The only reason I"ve hesitated up to this point is because JavaDoc now ignores/supresses any and all "@" parameters: @param, @author, @return, ... (why oh why?! ). But I've been a server-side geek my whole career, and now I want to learn GUI for first time. I also want to take advantage of regular expressions, and basically get with the times. So despite the plethora of "@" documentation being ignored (why oh why?! ), I took the leap. At least, in my local version.

Anyhoo, since I don't switch versions willy nilly (seems like more of a headache than what it's worth), I just have my Ant build.xml file clearly documenting the full CLASSPATH for each JDK, located at the top.

When I need to switch versions, I just overwrite the appropriate system environment CLASSPATH and JAVA_HOME variables to the version I want, in addition to a few other steps.

(I'm not really clear how the registry would be involved at all...unless you're manually manipulating the env. variables there, instead of right-clicking on My Computer.)

Here's the actual (more current and helpful than the online version) documentation in my ant file, word-wrapped so this forum thread isn't 18 screens wide :

Code: Select all

	JDK 1.3.1,  ANT 1.4

		CLASSPATH:
		.;C:\files\a_build\classes\production;C:\files\a_build\classes\t
		est_and_docs;C:\applications\java_development_kit\lib\tools.jar;
		C:\applications\java_ant\lib\ant.jar;C:\applications\java_ant\li
		b\xmlParserAPIs.jar;C:\applications\java_ant\lib\xercesImpl.jar;
		C:\applications\java_ant\lib\optional.jar;C:\applications\java_d
		evelopment_kit\jre\lib\rt.jar;C:\applications\java_servlets\serv
		let_with_jsp.jar;C:\applications\mysql\jdbc_driver\mysql-
		connector-java-2.0.14\mysql-connector-java-2.0.14-bin.jar

		JAVA_HOME:  C:\applications\java_development_kit

		Ensure z_javadoc_building_blocks\xbn_doclet contains the 1.3
		version of the JavaDoc standard doclet, and that all the code
		(1) compiles using the current XBN classes, and that the path to
		"doclet_class_map.txt" is correct.

		In SOBStringBuffer, ensure that the "1.3.1" section is
		uncommented, and the "1.4" section is commented.

	JDK 1.4,  ANT 1.5
		The problems I'm having when switching to 1.4 is 
	that no @param, @exception, @*anything* is displaying in the 
	JavaDoc output.

		CLASSPATH:
		.;C:\applications\java_development_kit_1_4\jre\lib\rt.jar;C:\app
		lications\java_development_kit\lib\tools.jar;C:\files\a_build\cl
		asses\production;C:\files\a_build\classes\test_and_docs;C:\appli
		cations\jakarta_ant\lib\ant.jar;C:\applications\jakarta_ant\lib\
		xml-
		apis.jar;C:\applications\jakarta_ant\lib\xercesImpl.jar;C:\appli
		cations\jakarta_ant\lib\optional.jar;C:\applications\java_servle
		ts\servlet_with_jsp.jar;C:\applications\mysql\jdbc_driver\mysql-
		connector-java-2.0.14\mysql-connector-java-2.0.14-bin.jar

		JAVA_HOME:  C:\applications\java_development_kit

		Ensure z_javadoc_building_blocks\xbn_doclet contains the 1.4
		version of the JavaDoc standard doclet, and that all the code
		(1) compiles using the current XBN classes, and that the path to
		"doclet_class_map.txt" is correct.

		In SOBStringBuffer, ensure that the "1.3.1" section is
		uncommented, and the "1.4" section is commented.