Why is the main() of Java void ?

[Gordon Beaton]

What is C89 and C99?

Common names of two C programming language standards:

C89: ANSI X3.159-1989
C99: ISO/IEC 9899:1999

/gordon

--

 

[Christopher Benson-Manica]

Java applications don't return anything at the end of main() - Java
applications return something when the application terminates. This
may be weeks after main() ended.

Uh, right. Got carried away on the C train of thought.

Unless forced to do otherwise, a Java application terminates when its
last non-daemon thread ends. If that thread ends normally (i.e. it
doesn't explicitly call System.exit(), Runtime.exit() or
Runtime.halt() but just runs to completion) then the app will
presumably return the "ok" value for the OS it runs on (normally 0).

I would also "presume" that the application would return the
"successful" return value in that circumstance, but I'm specifically
wondering whether the JLS or something else that's relevant specifies
the behavior.

 

[Christopher Benson-Manica]

Christopher Benson-Manica, 15.10.2007 21:05:

C89 says that the status is unspecified if the return from main() is
omitted; C99 implicitly returns a status indicating "successful".

What is C89 and C99?

They are both particular versions of the ISO C specification, named
for the years in which they were adopted. I mentioned them in the
hope that someone would quote an equally authoritative Java source
with some information regarding my question.

 

[Joshua Cranmer]

I would also "presume" that the application would return the
"successful" return value in that circumstance, but I'm specifically
wondering whether the JLS or something else that's relevant specifies
the behavior.

JLS 3 §12 (Execution) is the relevant section. About the only thing it
says about the main method is that its signature must be `public static
void main(String[] args)' (using a vararg method is also permissible),
that it is invoked, and this portion at the end:

§12.8 Program Exit
A program terminates all its activity and exits when one of two things
happens:
* All the threads that are not daemon threads terminate.
* Some thread invokes the exit method of class Runtime or class
System and the exit operation is not forbidden by the security manager.

Nothing at all is made mention of return codes or anything similar. I
could write a JVM that always returned 42 and it would still conform to
the JLS.

 

[Lew]

They are both particular versions of the ISO C specification, named
for the years in which they were adopted. I mentioned them in the
hope that someone would quote an equally authoritative Java source
with some information regarding my question.

The JLS doesn't say anything about an exit value from the JVM.

<http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.8>

Neither does the JVM spec:
<http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19152>

 

[Lew]

I would also "presume" that the application would return the
"successful" return value in that circumstance, but I'm specifically
wondering whether the JLS or something else that's relevant specifies
the behavior.

JLS 3 §12 (Execution) is the relevant section. About the only thing it
says about the main method is that its signature must be `public static
void main(String[] args)' (using a vararg method is also permissible),
that it is invoked, and this portion at the end:

§12.8 Program Exit
A program terminates all its activity and exits when one of two things
happens:
* All the threads that are not daemon threads terminate.
* Some thread invokes the exit method of class Runtime or class
System and the exit operation is not forbidden by the security manager.

Nothing at all is made mention of return codes or anything similar. I
could write a JVM that always returned 42 and it would still conform to
the JLS.

The JVM spec is equally silent on the matter of exit codes.

 

[Christopher Benson-Manica]

The JLS doesn't say anything about an exit value from the JVM.

<http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.8>

Neither does the JVM spec:
<http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19152>

Given that, is a conforming Java implementation free to return
whatever value it likes to the execution environment following the
termination of the JVM? That doesn't strike me as an especially
appealing situation.

 

[Patricia Shanahan]

Given that, is a conforming Java implementation free to return
whatever value it likes to the execution environment following the
termination of the JVM? That doesn't strike me as an especially
appealing situation.

I think the place this SHOULD be documented, and is not, is in the tool
documentation. For example, java-on-Solaris is a Solaris command, and
its documentation should specify its exit codes.

The JLS and JVM spec cannot even assume the implementation can return a
code to its environment.

Patricia

 

[Christopher Benson-Manica]

I think the place this SHOULD be documented, and is not, is in the tool
documentation. For example, java-on-Solaris is a Solaris command, and
its documentation should specify its exit codes.

That would be reasonable, however...

The JLS and JVM spec cannot even assume the implementation can return a
code to its environment.

....I feel that Java could have navigated that situation in a way
similar to the way that C has. Basically, the JLS/JVM could have
specified that implementations without a host environment (embedded
devices, for example) would be exempt from any restrictions concerning
return codes. For other implementations, an implementation-specific
"successful" execution status would be "returned" (i.e., not returned
if the environment wasn't interested) to the host environment. Given
that this is probably what occurs already without exception in all
host environments that expect a return code, it seems like formalizing
this convention wouldn't place any undue stress on any implementation
authors.

Obviously, this specification would only apply to "normal"
termination, not inherently system-specific situations such as an
uncaught runtime exception.

(Sorry to get long-winded there.)

 

[Wayne]

I think the place this SHOULD be documented, and is not, is in the tool
documentation. For example, java-on-Solaris is a Solaris command, and
its documentation should specify its exit codes.

That would be reasonable, however...

The JLS and JVM spec cannot even assume the implementation can return a
code to its environment.

...I feel that Java could have navigated that situation in a way
similar to the way that C has. ... Given
that this is probably what occurs already without exception in all
host environments that expect a return code, it seems like formalizing
this convention wouldn't place any undue stress on any implementation
authors.

Obviously, this specification would only apply to "normal"
termination, not inherently system-specific situations such as an
uncaught runtime exception.

(Sorry to get long-winded there.)

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Christopher Benson-Manica, 15.10.2007 21:05:

[comp.lang.java.programmer] Thomas Kellerer

In java you use System.exit(int) to return a status value to the OS

C89 says that the status is unspecified if the return from main() is
omitted; C99 implicitly returns a status indicating "successful".
What status does a Java program return to the host environment at the
end of main()? Is it specified?

What is C89 and C99?

The tradition in ANSI/ISO is to name the standards for
programming languages after the year the standard was
completed.

C89 is the C standard from 1989. C99 is the C standard from
1999.

Fortran 66, Fortran 77, Fortran 90, Ada 83, Ada 95 etc..

If SUN followed that standard Java 1.5 would be Java 2004 and 1.6
would be Java 2006.

Arne

 

[Roedy Green]

If SUN followed that standard Java 1.5 would be Java 2004 and 1.6
would be Java 2006.

I think that would be a great idea. You would have more luck mixing
software from the same vintage. You could tell what software likely
needed an upgrade.

I find it amusing when people have version numbers with 4 decimal
places. What is this fear of incrementing?

 

[Andy Dingley]

The tradition in ANSI/ISO is to name the standards for
programming languages after the year the standard was
completed.

Fortran 66, Fortran 77, Fortran 90, Ada 83, Ada 95 etc..

What are they going to do when Fortran wraps around the century?

 

[Lew]

The tradition in ANSI/ISO is to name the standards for
programming languages after the year the standard was
completed.

Fortran [sic] 66, Fortran 77, Fortran 90, Ada 83, Ada 95 etc..

What are they going to do when Fortran [sic] wraps around the century?

Presumably FORTRAN 07 or something similar.

 

[Eric Sosman]

Andy Dingley wrote On 11/05/07 07:50,:

What are they going to do when Fortran wraps around the century?

Fortran NT.

 

[Eric Sosman]

Roedy Green wrote On 11/04/07 18:37,:

I think that would be a great idea. You would have more luck mixing
software from the same vintage. You could tell what software likely
needed an upgrade.

I find it amusing when people have version numbers with 4 decimal
places. What is this fear of incrementing?

Knuth uses version numbers in a different way: not
to denote the amount of feature creep that has camel's-
nosed its way into the program, but to indicate that as
bugs are found and removed the program becomes a better
approximation to an unachievable Platonic ideal. He
writes of TeX and METAFONT

[...] the systems have been converging to an error-
free state. The latest and best TeX is currently
version 3.141592 (and plain.tex is version 3.1415926);
METAFONT is currently version 2.71828 (and plain.mf
is version 2.71). [...] My last will and testament
for TeX and METAFONT is that their version numbers
ultimately become $\pi$ and $e$, respectively. At
that point they will be completely error-free by
definition.

Yes, Knuth likes to crack the occasional joke in print, but
I think this passage also suggests a fixity of purpose, a
belief that the design is Right however faulty the execution.
This in turn suggests an attitude toward programming: Don't
write any code until you've finished defining the problem.
Hard advice for eager beavers like me to follow, unwelcome
advice for people who enjoy words like "agile" and "mash-up,"
but advice one would do well to ponder prior to rejecting.

 

[Lew]

This in turn suggests an attitude toward programming: Don't
write any code until you've finished defining the problem.
Hard advice for eager beavers like me to follow, unwelcome
advice for people who enjoy words like "agile" and "mash-up,"
but advice one would do well to ponder prior to rejecting.

It's quite possibly advice not even theoretically possible to follow.

Most programming problems are wicked problems. Small changes in the initial
approach to the solution space create big differences in implementation.
There is usually more than one equally "correct" way to solve the problem, for
various values of "correct".

Furthermore, "define completely up front" (a.k.a., "Waterfall") has been
proven a) not to work, and b) never to happen in real life.

Iterative development in the presence of a single person's architectural
vision has shown itself to be the most effective in practical terms.

 

[Eric Sosman]

Lew wrote On 11/05/07 17:24,:

[...]
Furthermore, "define completely up front" (a.k.a., "Waterfall") has been
proven a) not to work, and b) never to happen in real life.

Well, I *did* say the advice was hard to follow!
Still, "proven not to work" and "proven never to happen"
sound like overstatements. The counter-example, again, is
Knuth: How many "agile" developers hand out exponentially-
growing monetary rewards to people who find bugs in their
programs? Knuth does: he is offering $327.68 for the next
bug in either TeX or METAFONT. I think he started at $2.56
(one million in binary); if so, there have been only seven
bugs found in the two programs since their initial releases
more than twenty years ago. Would that the JRE were one-
tenth as solid!

We ordinary mortals may be unable to reach Knuth's high
standards, but his results speak for themselves -- and if
an ordinary mortal sniffs at the "proven not to work" methods
that produce results so much better than his own, he does so
at some risk of ridicule.

 

[Lew]

Lew wrote On 11/05/07 17:24,:

[...]
Furthermore, "define completely up front" (a.k.a., "Waterfall") has been
proven a) not to work, and b) never to happen in real life.

Well, I *did* say the advice was hard to follow!
Still, "proven not to work" and "proven never to happen"
sound like overstatements. The counter-example, again, is

Knuth: How many "agile" developers hand out exponentially-
growing monetary rewards to people who find bugs in their
programs? Knuth does: he is offering $327.68 for the next

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

We ordinary mortals may be unable to reach Knuth's high
standards, but his results speak for themselves -- and if

But your interpretation doesn't.

an ordinary mortal sniffs at the "proven not to work" methods
that produce results so much better than his own, he does so
at some risk of ridicule.

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.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

What are they going to do when Fortran wraps around the century?

Oh - Fortran 2003 is out and Fortran 2008 is in progress.

I chose the old ones, because they are more well known.

Arne