Tuesday, December 31, 2013

The method signature of a Java main method is:
public static void main(String[] args){
    ...
}
Is there a reason for this method to be static?
share|improve this question
add comment

31 Answers

This is just convention. In fact, even the name main(), and the arguments passed in are purely convention.
When you run java.exe (or javaw.exe on Windows), what is really happening is a couple of Java Native Interface (JNI) calls. These calls load the DLL that is really the JVM (that's right - java.exe is NOT the JVM). JNI is the tool that we use when we have to bridge between the virtual machine world, and the world of C, C++, etc... The reverse is also true - it is not possible (at least to my knowledge) to actually get a JVM running without using JNI.
Basically, java.exe is a super simple C application that parses the command line, creates a new String array in the JVM to hold those arguments, parses out the class name that you specified as containing main(), uses JNI calls to find the main() method itself, then invokes the main() method, passing in the newly created string array as a parameter. This is very, very much like what you do when you use reflection from Java - it just uses confusingly named native function calls instead.
It would be perfectly legal for you to write your own version of java.exe (the source is distributed with the JDK), and have it do something entirely different. In fact, that's exactly what we do with all of our Java based apps.
Each of our Java apps has its own launcher. We primarily do this so we get our own icon and process name, but it has come in handy in other situations where we want to do something besides the regular main() call to get things going (For example, in one case we are doing COM interoperability, and we actually pass a COM handle into main() instead of a string array).
So, long and short: the reason it is static is b/c that's convenient. The reason it's called 'main' is because it had to be something, and main() is what they did in the old days of C (and in those days, the name of the function was important). I suppose that java.exe could have allowed you to just specify a fully qualified main method name, instead of just the class (java com.myompany.Foo.someSpecialMain) - but that just makes it harder on IDEs to auto-detect the 'launchable' classes in a project.
share|improve this answer
15 
+1: Very fascinating (especially the part about writing a custom java.exe) –  Adam Paynter May 1 '11 at 9:15
3 
Interesting, I do disagree with the "This is just convention." Part of the answer. The OP's primary question was the reason for static in the declaration. I don't think static in the main() declaration is just for the sake of convention. The fact that it's `main()' and not something else is feasible however. –  Jared Jul 15 '12 at 1:15
1 
@David So it did. I actually would have preferred an answer from one of the people originally involved – but that was a very far shot. Most of the other answers are unfortunately an exercise in ad-hoc reasoning. This one gives quite interesting details, besides having the humility not to invent wrong technical details to reason away a (probably) non-technical cause. –  Konrad Rudolph Jul 17 '12 at 19:45 
1 
@BenVoigt You call LoadLibrary() to get the jvm dll. Then you call getprocaddress("JNI_CreateJavaVM"), then you invoke the JNI_CreateJavaVM function (docs.oracle.com/javase/1.4.2/docs/guide/jni/spec/… ). Once the VM is loaded you use standard JNI calls to find the correct class, load the static main method and invoke it. There's not a lot of room for misinterpretation there. JNI is absolutely how you load the VM. You may be used to writing only client side JNI using the native keyword, javah -jni, etc... but that's only half of JNI. –  Kevin Day Dec 5 '12 at 4:04
show 13 more comments
The main() method in C++, C# and Java are static because they can then be invoked by the runtime engine without having to instantiate an instance of the parent class.
share|improve this answer
7 
How would the JVM know which constructor to call, if your main class had overloaded constructors? What parameters would it pass? –  Jacob Krall Sep 29 '08 at 22:41
1 
@Noah when you say parent class do you mean the class containing the main method? Because if so, the term "parent class" is rather confusing here, and otherwise it would make no sense to me. Also, if by convention we use public static void main..., why couldn't the convention be that the application entry point class should have a public default constructor? –  Edwin Dalorzo May 12 '12 at 11:48
1 
@Jacob How would the JVM know which overloaded static void main to call? Not a problem at all. – Konrad Rudolph Jul 16 '12 at 22:00
show 3 more comments

Why public static void main(String[] args) ?

This is how Java Language is designed and Java Virtual Machine is designed and written.

Oracle Java Language Specification

Finally, after completion of the initialization for class Test (during which other consequential loading, linking, and initializing may have occurred), the method main of Test is invoked.
The method main must be declared public, static, and void. It must accept a single argument that is an array of strings. This method can be declared as either
public static void main(String[] args)
or
public static void main(String... args)

Oracle Java Virtual Machine Specification

The Java virtual machine starts execution by invoking the method main of some specified class and passing it a single argument, which is an array of strings. This causes the specified class to be loaded (§2.17.2), linked (§2.17.3) to other types that it uses, and initialized (§2.17.4). The method main must be declared public, static, and void.

Oracle OpenJDK Source

Download and extract the source jar and see how JVM is written, check out ../launcher/java.c, which contains native C code behind command java [-options] class [args...]:
/*
 * Get the application's main class.
 * ... ...
 */
if (jarfile != 0) {
    mainClassName = GetMainClassName(env, jarfile);

... ...

    mainClass = LoadClass(env, classname);
    if(mainClass == NULL) { /* exception occured */

... ...

/* Get the application's main method */
mainID = (*env)->GetStaticMethodID(env, mainClass, "main",
                                   "([Ljava/lang/String;)V");

... ...

{    /* Make sure the main method is public */
    jint mods;
    jmethodID mid;
    jobject obj = (*env)->ToReflectedMethod(env, mainClass,
                                            mainID, JNI_TRUE);

... ...

/* Build argument array */
mainArgs = NewPlatformStringArray(env, argv, argc);
if (mainArgs == NULL) {
    ReportExceptionDescription(env);
    goto leave;
}

/* Invoke main method. */
(*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs);

... ...
share|improve this answer
1 
The problem here is that this is actually a very good answer to the question in its original form, with plenty of references (+1). However, I’d love to learn about the rationale for the design decision of making a static method the entry point, rather than a constructor or instance method. –  Konrad Rudolph Jul 12 '12 at 6:57
1 
@KonradRudolph, for questions regarding to language and JVM specification design, perhaps you could try contact original source from Oracle and see if you can get any positive feedback. –  yorkw Jul 12 '12 at 9:27
1 
Generally speaking when a method result computation depends only on its parameters, so that it does not depend on the object instance internal state, it can be static. And it is recommended to set it as static for code maintainability/re-usability. If the method main was not static, it means the class instance state must be known and it is much more complex to define, like which constructor to use first. –  Yves Martin Jul 15 '12 at 21:38
1 
@Yves It can be. It needn’t, if another design makes sense. I’ve heard some good arguments in the comments here but I still think that a process is effectively very much like a thread (it is), and a thread in Java is usually represented as an instance of Runnable. Representing the whole process in the same way (i.e. having Runnable.Run as the entry point) definitely makes sense in Java. Of course, Runnable itself is arguably a design flaw, caused by the fact that Java doesn’t have anonymous methods (yet). But since it’s there already … –  Konrad Rudolph Jul 16 '12 at 15:30
show 1 more comment

No comments: