Signature of main

A

aruna

Why the signature of main is, public static void main(String
args[])?What is the significance?
 
B

Bjorn Abelli

...
Why the signature of main is,

Because the JVM must be able to access it...

Because it's a *class* method, as no instances of the class can have been
instantiated until the application is actually started...

Because it doesn't return anything...

Because of the heritage from C/C++ they chose
the same name...
(String args[])

So the application can take arguments from e.g. the commandline...


Finally:

comp.lang.java.help

....would be a better place to post questions when you're new to Java.

// Bjorn A
 
K

Karthik

aruna said:
Why the signature of main is, public static void main(String
args[])?What is the significance?

It is static because , it is entry point of the java program and so it
has to be invoked by the JVM.

String [] args - refer to command-line args.

void return type - since , I am not too sure if it makes any sense to
have 'int' as return type.
That information can only be used only by the JVM that invoked it.
Even if the JVM-level java code exist abnormally, the OS-level 'java'
application might exit normally.

HTH
 
R

Roedy Green

Why the signature of main is, public static void main(String
args[])?What is the significance?

When java.exe loads your class, it needs to know which method to call
to get it started.

They had two choices, make you specify it on the command line or use a
standard name. They chose a standard name. It also has a standard
parameter list for getting the arguments.

See http://mindprod.com/jgloss/main.html
 
C

Chris Uppal

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.
 
G

Guest

aruna said:
Why the signature of main is, public static void main(String
args[])?What is the significance?

There is no need to have a such
public static void main(String args[]))
entry-point.

Please consider the following example:

public class HelloWorldWithoutMain {
static {
System.out.println("Hello World");
System.exit(0);
}
}

It works and it does not have any main method !

- Dario
 
L

Liz

wow, it DOES work

Dario (drinking coï¬?ee in the oï¬fceâ?¦) said:
aruna said:
Why the signature of main is, public static void main(String
args[])?What is the significance?

There is no need to have a such
public static void main(String args[]))
entry-point.

Please consider the following example:

public class HelloWorldWithoutMain {
static {
System.out.println("Hello World");
System.exit(0);
}
}

It works and it does not have any main method !

- Dario
 
P

P.Hill

Liz said:
wow, it DOES work

But since java will follow the protocol of finding a main, it is
not a particularly useful bit of Java trivia.

Apparently both java in Eclipse and JDK java politely
ingnores the absense of a main and it apparently runs.
But as soon as you want to do real work you run into
trouble:

public class HelloWorldWithoutMain {

static {
System.out.println("Hello World");
bomb();
System.exit(0);
}

static void bomb() throws Exception {
throw new Exception( "Ooops!");
}


// public static void main(String[] args) {
// }

}

The above does not compile, because
the static initializer calling a method which is declared
to throw an exception is not allowed.

The JLS says:
"It is a compile-time error for a static initializer to be able to complete
abruptly"
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#39245

Assuming you don't care what happens to the error, when
declaring a main all you have to do add "throws Exception" if you are calling
something which throws a checked exception; meanwhile, in a static initializer
you have to add a try/catch.

So trying both variations in the same class (and dropping the exit(0), so
we get the default exit behavior and each solution will continue), we have:

public class HelloWorldWithoutMain {

static {
try {
System.out.println("Hello World in static initializer.");
bomb();
} catch ( Exception e ) {
e.printStackTrace();
}
}

static void bomb() throws Exception {
throw new Exception( "Ooops!");
}


public static void main(String[] args) throws Exception {
System.out.println("Hello World from main.");
bomb();
}
java HelloWorldWithoutMain
Hello World in static initializer.
java.lang.Exception: Ooops!
at HelloWorldWithoutMain.bomb(HelloWorldWithoutMain.java:19)
at HelloWorldWithoutMain.<clinit>(HelloWorldWithoutMain.java:12)
Hello World from main.
Exception in thread "main" java.lang.Exception: Ooops!
at HelloWorldWithoutMain.bomb(HelloWorldWithoutMain.java:19)
at HelloWorldWithoutMain.main(HelloWorldWithoutMain.java:25)

In a real world app, the main() variation would probably also have
a try/catch so to have logging or something.

have fun with those language quirks,
-Paul
 
R

Roedy Green

Apparently both java in Eclipse and JDK java politely
ingnores the absense of a main and it apparently runs.
But as soon as you want to do real work you run into
trouble:

Some wombs don't insist that main be public.

I have a main as a macro I click with an Icon in slickEdit. I don't
have to think about all the bubblegum to make it work. It is just
Main.

The problem with lax wombs is code seems to work, then stop working
mysteriously when taken elsewhere.
 
S

Steven J Sobol

Karthik said:
aruna said:
Why the signature of main is, public static void main(String
args[])?What is the significance?

It is static because , it is entry point of the java program and so it
has to be invoked by the JVM.

String [] args - refer to command-line args.

void return type - since , I am not too sure if it makes any sense to
have 'int' as return type.

Sure it would - could be used to return a status code - many programs
do this under Unix and its variants, and you can do it under Windows too.

--
JustThe.net Internet & New Media Services, Apple Valley, CA PGP: 0xE3AE35ED
Steven J. Sobol, Geek In Charge / 888.480.4NET (4638) / (e-mail address removed)
Domain Names, $9.95/yr, 24x7 service: http://DomainNames.JustThe.net/
"someone once called me a sofa, but i didn't feel compelled to rush out and buy
slip covers." -adam brower * Hiroshima '45, Chernobyl '86, Windows 98/2000/2003
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top