aruna said:
Why the signature of main is, public static void main(String
args[])?What is the significance?
You've already had the simple and informative answer. So lets try a different
tack ;-)
(Aruna, if all you wanted was the simple answer then please ignore the rest of
this if it seems at all confusing)
This is a rather deep question, and I think it's worth exploring it a little.
But first the executive summary:
There's no special reason. It is, at best, arbitrary and
was chosen to look familiar to C/C++ programmers.
Anyway....
The things to find explanations for:
"public"
"static"
"void"
"main"
"(String[] args)".
Let's take them in order.
"public" -- there's no reason for this at all. The code is invoked from the
java.exe program (as it's called on Windows), which is just a C/C++ program[*]
which uses the standard JNI API to find a method and call it. Since JNI is
unaffected by Java's "protection" levels, there's no special reason why this
should be constrained to be "public". I could make an argument that it'd be
better if we were allowed to define private entry-points if we felt the need.
(After all, just because we want an application to be launched via main(),
doesn't mean we necessarily want to allow random other code to call it too.)
"static" -- this is a dodgy decision too. Java is supposed to be about OO, but
you can't write /any/ application without using the OO-violating "static"
construction! It seems that a better entry-point (in the sense that it'd fit
better with the mindset that Java is intended to encourage) would be for the
launcher to create an instance of some nominated class (using the no-args
constructor, say) and then invoke a method of that instance. You'll note that
that's what any real program ends up doing anyway (broadly speaking), so making
main() static just adds unnecessary clutter.
"void" -- /this/ decision I approve of. In languages like C the intended
picture
of the execution is as procedural breakdown. main() calls a sequence of other
functions, which in turn are broken down into still further functions, and so
on. (I can't remember the proper name for this, "procedural decomposition" or
something like that -- and it can be contrasted with OO programming). In the C
mindset, it's natural that when main() finished, that's /because/ the program
has finished, and so the "int" return value is naturally the status returned to
the execution environment. In OO programming (even without threads) that
picture is wrong, or at least uncomfortable. The /objects/ and their
interactions constitute the program, and the fact that one method somewhere as
returned does not mean (as it were) the end of the world. It'd be better to
represent the external environment /within/ the world of objects. So the
"right" way to exit the program should be to call some exit(int) method on some
object somewhere. (Unfortunately Java doesn't quite get this right -- I remain
convinced that Gosling et al, didn't really understand OO when they designed
Java -- but still, returning void from main() is a step in the right
direction.)
"main" -- well, I suppose it had to be called /something/. But why not a more
intention-revealing name like applicationEntryPoint() ? It's not as if main()
is a method we call, or define, often. This point is especially obvious if we
think that the launcher "should" create an instance of a nominated class, then
invoke a defined non-static method. Perhaps it'd be better for the invoked
method to be caller-nominated too. So the launcher command line would look
more like:
java org.whatever.Main.doSomething
which would create an instance of org.whatever.Main and invoke its
doSomething() method.
"(String[] args)" -- hmm. This is odd. If we accept that main() returns void
rather than "int", because falling off the end of main() is not how passing a
status back to the invocation environment should be represented in an OO world,
then the same argument should apply to passing data
/in/ from the environment. I.e. I think it'd be more natural for there to be a
defined object in the runtime that represents the invocation environment, and
for /it/ to have methods for finding the "command line" parameters (which
don't, of course, necessarily come from the command line -- I suspect that they
typically don't). That means that the code for the interpretation of the
parameters could be placed where it "wanted" to live, rather than having to be
called explicitly by main(). After all, none of the other information from the
environment is passed in to main() in that way -- why should command-line
parameters be treated differently ?
Incidentally, it'd be possible to write a launcher (and a few support classes)
that worked exactly this way. So there's no /technical/ reason why Sun didn't
choose this approach. I suspect they defined the entry-point in the way they
did because:
(a) a failure of "vision"
(b) to be familiar to C programmers
and perhaps, too, because:
(c) it was easier to document (which may be no bad reason).
Another incidental observation: In case the picture I've painted above sounds
unwieldy, I do have experience with a system (a flavour of Smalltalk in fact)
that works not too unlike what I've suggested. From experience with it, I'd
say that the more OO way of working is in fact easier to program with. (And
surely must be easier to teach.)
-- chris
[*] the source for the Java executable is part of the standard JDK and, I
believe, the licence permits you to modify it, and distribute the resulting
programs. I.e. Sun /want/ us to be able to use different launchers if we wish.