Info - com.sun.tools.javac.Main is not on the classpath

[Andrew Thompson]

For information only - no question here..

I hit this error and went searching the groups for answers.
Failed to find the solution to this particular problem, so
I thought I'd post the fix to this (particularly stupid)
mistake I made.

When compiling from the command line, I might set
JAVA_HOME like this.

set JAVA_HOME="C:\Program Files\Java\j2sdk1.5.0\"

Note that the " are required because of the space
in the name of 'Program Files'.

Very soon I got sick of typing that every time, and
put it as an environment variable using regedit.

Key: JAVA_HOME
Value: "C:\Program Files\Java\j2sdk1.5.0\"

This seems to work when referenced from the command
line or .BAT files, but most IDE's and Ant are tripped up
by it. The quotes now cause the string to fail to find the
tools.jar (which is in the lib\ subdirectory of the SDK).

It should be something more like (adjust for local system)..

Key: JAVA_HOME
Value: C:\Program Files\Java\j2sdk1.5.0\

After removing the extraneous quote marks,
(and rebooting), it worked just fine.

( Hopefully - next time I forget this fix, stuff it up
again and come looking for answers, I'll *find* this
again..

Andrew T.

 

[lordy]

When compiling from the command line, I might set
JAVA_HOME like this.


Note that the " are required because of the space
in the name of 'Program Files'.

Yes. The quotes are required *by the DOS shell*.

Not sure what OS you are using but you can set env.vars
under (from memory) Control Panel->System-> Performance
or something like that
then there is a tab called Environmental Variables. Which
then presents a piss-poor dialog to enter your variables.
(But still a bit safer than firing up regedit)

However I have generally preferred not setting JAVA_HOME here
if I have multiple java based applications, but making sure they
each set their own JAVA_HOME independently in their own config files.

Lordy

 

[Andrew Thompson]

Yes. The quotes are required *by the DOS shell*.

Not sure what OS you are using but you can set env.vars
under (from memory) Control Panel->System-> Performance
or something like that
then there is a tab called Environmental Variables.

XP Pro, and ..checking

Settings | Control Panel | System | Advanced |
Environment Variables | (System Variables) New

....Which
then presents a piss-poor dialog to enter your variables.
(But still a bit safer than firing up regedit)

I reckon running regedit is almost as safe as
'home brain sugery'.

However I have generally preferred not setting JAVA_HOME here
if I have multiple java based applications, but making sure they
each set their own JAVA_HOME independently in their own config files.

Good point. I generally prefer that myself, but
there are times/situations that the 'set and forget'
nature of enviroment variable can save a lot time.
OTOH, this example illustrates one of those
/other/ times when several hours is wasted in
tracking down the trivial mistake.

Andrew T.

 

[ge0rge]

Andrew Thompson wrote:
....
install the jdk on C: drive and it will create c:\j2sdk1.5.0\ directory and you
get rid of the potential space problem in the directory name once and for all.

 

[IchBin]

Andrew Thompson wrote:
...

install the jdk on C: drive and it will create c:\j2sdk1.5.0\ directory
and you get rid of the potential space problem in the directory name
once and for all.

Or do a 'dir /x' and use the 8 byte dir name. Any Time I have problems
with spaces in a dir name I use the MS's 8 byte dir name.

--

Thanks in Advance...
IchBin, Pocono Lake, Pa, USA http://weconsultants.phpnet.us
__________________________________________________________________________

'If there is one, Knowledge is the "Fountain of Youth"'
-William E. Taylor, Regular Guy (1952-)

 

[Chris Uppal]

Or do a 'dir /x' and use the 8 byte dir name. Any Time I have problems
with spaces in a dir name I use the MS's 8 byte dir name.

Or better yet. Track down the software that is unable to deal with spaces in
filenames and remove it from your system. This applies to both Windows and
Unix-alikes -- there is /NO/ excuse for a program to be bothered by spaces[*].

Oh, and software which wants to install to the root of the C: drive is also a
sign[**] of software that you'd be better off without.

-- chris

[*] Newlines in filenames, now, can be a different matter -- but only allowed
on Unix, IIRC, and not /very/ common, even there.

[**] Not a /certain/ indicator, but a pretty strong hint...