Then it would work from the command line interactively, not from a .bat, correct?

The situation in C and Java are not the same.  A single instance of
a JVM may run multiple Java programs/applets.  Just because your Java
program has ended doesn't mean the JVM will end then; it may run
additional Java programs before terminating.  The System.exit() call
terminates a JVM (which has the side-effect of terminating any running
Java programs in that JVM), and is not the same as exiting from a C
program.  There is no direct way for the JVM to inform the underlying OS
some Java thread's return status without exiting itself.  That would be
a problem for some long lived JVMs, such as the ones running applets
in your web browser (one reason why applets are not allowed to
call System.exit() ), or in a server, or in a cell phone, or in an
embedded system.

The JVM always (almost) terminates successfully, regardless of result
of any Java programs running on the JVM.  From the OS point of view,
the "program" you ran was "java.exe" and not "HelloWorld.class".
Whether or nor your .class "program" ran as expected, the JVM did
complete normally.  An anology would be to have a word-processor
program return a failure exit status, if one of the documents you
edited contained any spelling errors.  The OS only cares (and
only rarely) if the *process* it just cleaned up exited successfully.
The OS doesn't really care to know what the process did prior to
that.

The seeming similarity to C is only because "classroom" programs tend
to start a JVM, run a single "Main" thread, then terminate the JVM.  So
there is the illusion that System.exit() returns the exit status of your
program rather than the exit status of the JVM.  While in some cases
System.exit() can be abused to return a value for your "program", I
think you'll fine in real life such situations are the exception
rather than the rule.

If you want a program (or just a thread) to let the calling environment
know there was a problem, there are much better ways then
attempting to return a one byte int!  Logging, MBeans, Java message
service, Sending output to System.err, or even opening a socket to
communicate termination status to another (waiting) program are some
methods that leap to mind.

Note that the JVM *does* return a meaningful exit status, even in
the cases we are talking about:

public class ExitStatusDemo
{  public static void main ( String [] args ) {
     if ( args.length != 0 )
        throw new RuntimeException( "Opps!" );
  }
}

I think you'll find that if a program throws an uncaught
exception, the JVM terminates with a non-zero exit status.

I think the designers of Java's main method got it right.  It
should be a void method.  You need to handle your programs
errors internally or in some systematic way.  Leave the exit
status as a JVM exit status, not some poor-man's communication
channel between programs.

-Wayne

<http://www.amazon.com/Wicked-Problems-Righteous-Solutions-Engineering/dp/013590126X>

Knuth is not a counter-example.  Did he follow waterfall?

But your interpretation doesn't.

What methodology did Knuth follow?  Where is it documented?

He followed the "one person's vision of the architecture" that I said does
work, surely.

If you are as talented and meticulous as Donald Knuth is, you don't
need an externally-imposed process to produce solid software.  All of
these external processes are intended to be checks and balances on
more average programmers, like most of us.