creating a file,compiling using javac,

hi guys
actually i am new in java and i am having difficulty using my command prompt to create a new file called HeloWorld.java
also i tried to compile but it kept telling me my commands are not recognised.please can someone just put me through using the command prompt starting from the scratch.thanks a million

Have you tried the steps described in Sun's tutorial http://java.sun.com/docs/books/tutorial/getStarted/cupojava/win32.html ?

It includes an explanation of the "'javac' is not recognized as an internal or external command" problem, and what to do about it.

that error usually means that your bin folder isn't in the path.

umm you can change this by right clicking on My Computer.

then clicking on the Advanced Tab.

Clicking on the Enviromental Variables button at bottom.

then search for path in bottom box.

highlight it.

then click on edit.

then if you have any path already in the box that pops, put a ';' after it.

and the type in.. (C:\Program Files\java\jdk1.5.0_06\bin

that should fix it...

or you can locate the bin folder, and put the java file in there.

and in command prompt type the following.

cd C:\

then type:

cd Program Files\java\jdk1.5.0_06\bin

then you can use the java compiler which is 'javac' on the file in the

bin folder.

hope this helps

oh and the folder jdk1.5.0_06 , that's only the folder if you have that

version of java.

you can check the name of the folder by double clicking on My Computer

then Click on C:\

then on program files

then on Java

and you'll see it, usually the jdk folder and jre...

use the jdk one.

-Justin-

or you can locate the bin folder, and put the java file in there

I really don't think it's a good idea to mix executables (like javac.exe) and data files (like your .java files). They really should be
in different places to allow orderly filing, backups and so forth. On a
multiuser setup you definately don't want all and sundry dumping their .java
files in the bin directory!

Justin's first suggestion is the way to go (in my opinion).

Originally posted by Peter Brockway:
I really don't think it's a good idea to mix executables (like javac.exe) and data files (like your .java files). They really should be
in different places to allow orderly filing, backups and so forth. On a
multiuser setup you definately don't want all and sundry dumping their .java
files in the bin directory!

So would you set up your PATH differently if you don't place your data files in the \bin?

Originally posted by Steph Cantrell:

So would you set up your PATH differently if you don't place your data files in the \bin?

No, the Path variable in enviromental variables(assuming windows) needs to point to /bin. that is how it finds javac and other goodies included in the JDK.

If you are compiling on the command line, the command line needs to point to where the .java file is.

Assuming packages are not used and the .java file is in C:\projects\helloworld, the command prompt should look similar to this

C:\projects\helloworld>javac HelloWorld.java

To move from file to file use the cd command. Or what I think is easier, make a shortcut to command prompt on the desktop, right click, go to properties, then put the path in the start in box.

would you set up your PATH differently if you don't place your data files in the \bin?

No, as I said, the PATH variable should be set up to include
the location of the java executables (aka the bin directory).
Usually this happens when you install the software, but if
it doesn't for some reason then the procedure for adding it
described by Justin is effective.

The question of where java and javac find .java and .class
files is different. They can use a different variable,
CLASSPATH, but I don't recommend setting this environment
variable as it is very inflexible.

The directory structure for a very simple HelloWorldApp
(packageless) application might look like this:

My PATH includes c:\program files\java\java1.5.0_06\bin and CLASSPATH
is unset. I would compile and run with

The important thing is that I use the -cp switch to specify
the classpath explicitly. The "dot" meaning "this directory".

im not trying to be a smart A or anything, but...

you used javac -cp . helloworldapp.java

then java -cp . helloworldapp

couldn't you not use the -cp and be ok? I mean your already in the

directory where the helloworldapp.java currently resides.

please help clarify.

oh and about the "finding the bin folder and putting the .java files in

there." I didn't really think it would hurt anything. When i first

started to use java, that's what i did. I don't know all that much.

how could it mess something up?

-Justin-

[ May 03, 2006: Message edited by: Justin Fox ]
[ May 03, 2006: Message edited by: Justin Fox ]

couldn't you not use the -cp and be ok? I mean your already in the

directory where the helloworldapp.java currently resides.

I think that's only the case if the CLASSPATH variable is already defined and contains '.'.

Yuriy

Originally posted by Yuriy Zilbergleyt:

I think that's only the case if the CLASSPATH variable is already defined and contains '.'.

Or -- and here's the important point that so many folks seem to miss -- if CLASSPATH isn't defined at all! The very best setting of CLASSPATH for people new to Java (and frankly, for everyone) is for this variable to be unset. The default classpath is then just ., the current directory, which is exactly what is most helpful.

Originally posted by Justin Fox:

oh and about the "finding the bin folder and putting the .java files in

there." I didn't really think it would hurt anything. When i first

started to use java, that's what i did. I don't know all that much.

how could it mess something up?

-Justin-

[ May 03, 2006: Message edited by: Justin Fox ]

[ May 03, 2006: Message edited by: Justin Fox ]

I don't think it would hurt anything, as in corrupt what belongs in /bin. I could be wrong though. There is a reason why there is a file system. Files that go together should be in the same folder, or folder system. bin is short for binary, so that file should hold binaries. In this case JDK binaries. Why? Because, that is what the file system implies. It all comes down to neat housekeeping.