Classpath problem on WinXP Pro
I'm sorry to add another question about classpath but I haven't found any of the other posts to be of help.
I've installed JDK 5.0 Update 11 with NetBeans IDE 5.5 and accepted the default directories:
C:\Program Files\Java\jdk1.5.0_11
C:\Program Files\Java\jre1.5.0_11
I set the Path to the jdk bin directory and all is well.
However, when I set the classpath variable, there are errors.
When I execute at the cmd promt:
set classpath=C:\Program Files\Java\
jdk1.5.0_11\jre\lib\rt.jar
and then:
%classpath%
I get:
'C:\Program' is not recognized as an internal or external command, operable program or batch file.
It's clear that the classpath parm doesn't like the space in the path.It also wouldn't accept a period, as suggested by a tutorial:.;c:\program files etcfailed at the period.
On an older machine (also Win XP Pro, sp2) that my current one replaced, I didn't have that problem. It had a similar directory structure, but I don't remember what I did when I changed it.
What am I doing wrong?
Many thanks.
[1154 byte] By [
adrien1a] at [2007-11-27 3:17:42]
I think the command you meant to execute was echo %classpath% However, you really shouldn't be setting the classpath variable at all, and you definitely shouldn't include rt.jar in it. As long as you call the right version of the executable (java.exe, javac.exe, etc.), it will find the correct copy of rt.jar on its own. Adding rt.jar to the classpath does no good, and may introduce very hard-to-find bugs. Also, if you try to compile and run a simple "Hello world"-style program in the default package, you might find that it doesn't work, for a very annoying reason. If you leave the classpath in its default setting, the JVM automatically looks in the current directory for any classes you refer to in your program. But if you set the classpath, either through the environment variable or via the -cp option, it no longer looks in the current directory unless you specifically add "." to the classpath: set CLASSPATH=C:\Test\mylib.jar;.
> set classpath=%classpath%c:/program files/jdk1.5/bin;
No. The bin directory belongs in the PATH variable, not CLASSPATH, and the OP already has PATH set correctly. Also, you left out the semicolon after %classpath%, you got the path to the bin directory wrong, and you neglected to include the current directory.
Thanks, uncle_alice.I restored the classpath variable to what it was before:.;C:\Program Files\Java\jre1.5.0_06\lib\ext\QTJava.zip
Is that suitable or should that be changed because of installing the JDK.
Now that I know that my classpath really wasn't a problem, I reexamined my code and realized I misspelled System.out.println as printlin.
I also noticed that MSSL's suggested was for Unix, since it had forward slashes.
Thanks again.
If that folder still exists, and the zip file is still in it, and Quicktime is still installed, you can leave it the way it is. Be aware, though, that every Java "update" is really a complete installation, which means any older installations are just taking up space. If you decide to reclaim that space, you'll need to move that zip file somewhere else and update the classpath accordingly. Or you can do what I did, and banish Quicktime and RealPlayer from your system. I hate pushy programs, and those are two of the worst I've ever dealt with.
I don't know why they put that zip file there anyway. On the one hand, anything in the lib/ext folder in the current version's directory tree gets added to the classpath automatically. On the other had, as soon as you install an update or a new version, the older installation's lib/ext folder stops being special. The Quicktime people seem to realize that, too, since they went ahead and added it to the classpath as well. But wouldn't it make more sense to put the zip file somewhere else entirely, and not have to deal with the JRE churn at all?
By the way, Windows will accept forward slashes in place of backslashes in file paths. You see? Even Microsoft is capable of learning that pushiness can be taken too far. Of course, they still have a long way to go...
