Not really. GUI editors can be, but I don't use them. An IDE's primary
use is to do menial tasks for you to make you more productive. This is a
blessing for programmers who know what the IDE does for them. It is not
useful for beginners, as they also need to learn those things. If the IDE
does it for them, they won't learn.

The path used by the system is where the system looks for executables. The
classpath is where Java looks for classes.

Ah, you've run it by double-clicking it. This script is too simple for
that. Call this script as you would call the java compiler (with the
classes to compile as an argument). Then it'll work.

No. The system API is silently included in the classpath by the JRE/SDK.
That's why Tomcat needs the SDK installed: not just for the compiler and
JRE, but also for the system classes.

As stated above, it silently adds them to the classpath, and pulls them
from the installation (most likely %JAVA_HOME%\jre\lib\rt.jar).

In the hosting environment, the JRE does the same thing as on your
computer: it silently adds the system API from wherever it is installed
(assuming noone moved it after installation), adds it to the classpath,
etc.

If they say so: do this. These are specific installation instructions for
deployment at their server. For your home machine, try not to do this for
the environment of Tomcat.

This is far from simple. The simplest would be to create a command line
program. First one that has it's parameters hard-coded, then one that
parses either command line arguments or user input.

To compare:

For a command line application you need to:
- Have a basic understanding of Java
- Implement what you want the application to do
- Parse user input
- Know how to invoke the java runtime

For a web application you need to:
- Have a basic understanding of Java
- Implement what you want the application to do
- Parse user input
- Have a basic understanding of J2EE/web applications
- Know about HTML
- Know how HTML form values are represented by the request
- Know how to deploy a web application
- Know how to configure a J2EE container such as Tomcat (because your
 hosting provider appearently doesn't have a default installation).

Note that the first three items are the same.

Yes.

Compilation goes well. Deployment doesn't.

The locations used within a web application is NOT the location on disk:
it is the location on the server (i.e. what you type in the address bar
of your browser).

I still think your problem is that Tomcat cannot find a class in the
default package (which is where you put cc now). What happens is you put
it in another package, say com.fdr? The location of the servlet as known
by the form would then be "servlet/com.fdr.cc".

You are confusing an IDE with an IDE that had GUI building tools. IDEs
are handy in that they make a lot of mundane tasks easier.

For example:

When you compile your application in a DOS window, you need to append
the classpath. In my IDE (and most IDE's have similar functions), I
make a Java project, and add the libraries to the projects properties
(in Eclipse, go to project properties -> Java Build Path -> Libraries
Tab, and add additional Jars for that project. Now, whenever I
compile, It happens immediately.

Using ANT provides similar functionality. If you prefer to compile on
the command line, then Ant allows you to script your build process.
Similar to writing a DOS bat file, but is a lot more conducive to
building Java programs. And example similar to yours would have a
build.xml file like this:

<project name="My Servlet" default="compile" basedir=".">
 <path id="my.classpath">
   <pathelement path="path.to.my.servlet.jar"/>
 </path>

 <target name="compile" description="compiles">
   <javac srcdir="src" destdir="build" classpathref="my.classpath"
includes="**/*.java"/>
 </target>
</project>

This is just a very simple example. Other things Ant (and IDEs as
well) do is deploy to Tomcat, start Tomcat, run Java applications, you
name it.

--
now with more cowbell

I also strongly recommend using Ant.  

Take a look at some of the Jakarta projects and you'll find that all of them
use Ant to compile, deploy, build the documentation, and create
distributions.  I also use it for running unit tests and have even used to
for xml/xslt transformations to turn documents written in xml into pdf
files.

If you're writing java servlets, I recommend reading the following page:

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/appdev/index.html

While it is for Tomcat 4.1, it's mostly applicable for Tomcat 5.0 and
describes how to set up a build directory, where to put source code other
files necessary for building a web application.  Then use Ant with that
recommended directory structure to build and deploy applications.

Frances Del Rio <fdr58@yahoo.com> said:

Servlets are part of the full J2EE specifiation, so in that sense you
do need J2EE for servlets. But then, J2EE is vastly more than just
servlets and JSPs.

Forget 'enterprise' for a good while; so even if formally you're using
J2EE by writing servlet/JSP applications, let's just say you're writing
servlet/JSP applications, and not fuss about the J2EE.

As for Java Beans, they're objects modelled according to a simple set
of principles (and not to be confused with "Enterprise Java Beans",
which are something different, and usually not so simple).

Beans (regular, not EJB) should be considered as a bunch of related
data fields with methods to set and retrieve the values of individual
fields (instead of providing direct access to the field values). So,
you might have

public class Person {
    private Float weight;
    private Float height;

    public Float getWeight()
    {
        return this.weight;
    }

    public void setWeight(Float w)
    {
        this.weight=w;
    }

    // and similarly for height
}

... and this is a Java Bean in its most basic form:
- it has private data fields
- it has non-private methods to get/set values of the fields
 (and the method names correspond to the names of the data fields,
  with the exception of the regular change in capitalization)
 - no parameters for the get-methods
 - void return type for the set-methods
- read-only fields are supported, by simply not providing the
 set*() -method (but then, the value must be set using some other
 way; in class constructor, as constant value, or as a side effect
 of setting some other data field)
- "virtual" fields are also allowed (and these would be good
 candidates for read-only fields); so, the above class could have
 a getWeightIndex() method (to return the weight index for the person,
 calculated from the stored weight and height, but not stored anywhere)

The published interface (set of get- and set- methods) is the most
important feature of a Java Bean. Internals can be implemented in
whichever way is seen suitable.

So, a Java Bean is a very nice, very basic object. At first it looks like
it's too simple to be of any real use, but surprisingly it is rather
handy in suitable cases (and the more advanced forms do quite a lot of
magic behind the get/set -method scene).