Public Static Void Main

The infamous PublicStaticVoidMain of JavaLanguage, although it is found in other object-oriented languages. Could be considered a static GodMethod, as it does everything. As RodrigoBarretoDeOliveira? (creator of BooLanguage) said,

The guys who came up with “public static void main” were probably kidding, the problem is that most people didn't get it was a joke.

I don't get it. Is it a naughty joke? "I'll void my main in public" sounds a little shameful.

No, he was referring to the fact that PublicStaticVoidMain is just too much to type for one "Hello, world!"

PublicStaticVoidMain in all its (un)glory:
	class HelloWorld {
	   public static void main(String[] args) {
		System.out.writeln("Hello, world")
A class that will never become an object, with one method, which I have to specify is public, static, and has a return type. Compare to PythonLanguage
	print( "Hello, world!" )
Or, if you want import-ability:
	def hello_world():
	print("Hello, world!")
	if __name__ == "__main__": hello_world()
Isn't this only an issue if you never write programs more complex than print("Jello, Whirled")?

Well, I wish that at least the compiler were smarter. If I could write main {...} or void main() {...}, it would be OK, but I have to put that it has a return type, which must be void or the program crashes. I mean, the thing is, all of these don't work: Poor baby. On a big project, that takes, what, a few seconds to find and fix? Then you never have to worry about it again. Relatively speaking, it consumes 0.000001% of the project development effort. Big, hairy deal.

So you're saying 'Just type it in'? See JustIsaDangerousWord.

Small hairy deal, but it just creates a lot of yuck.

One line of code creates "a lot of yuck." Oookay... Glad to see you've got a healthy perspective.

What's also annoying is that JavaLanguage has no modules, just classes with static methods--not a big thing, but the UgLyness piles up quickly.

You're awash in suffering, aren't you?

I give up. I try to give my own justification for not using JavaLanguage...

Sounds like you're rejecting an entire enterprise-grade, OpenSource, portable platform on the basis of a couple of minor language quirks, neither of which impact significantly on productivity or at all on code reliability. Baby, with bathwater, tossed.

<Gets HolyWarUmbrella out> I'd rather use the CommonLanguageInfrastructure than the JVM, anyway. (Though, I wouldn't mind JythonLanguage (JayPythonLanguage??))

[Edit--hello, it's me again...I'm sorry I got into an argument with you guys. This page was mostly meant to express how silly it is to have to type PublicStaticVoidMain for even the simplest programs; it was never meant to become an argument about whether to dump JavaLanguage over something that small.]

[That being said, ScalaLanguage has closures and InternalIteration, and you write "object HelloWorld extends Application { println("Hello, world!"); }"...and it's also for JVM...]

[Oh, one more thing--it's not just PublicStaticVoidMain, it's...Execution in the Kingdom of the Nouns that I hate...Not everything is fit to be refactored into a class...]

True, but in Java the concept of "class" is overloaded to represent both stateful objects and modules. A "class" consisting entirely of static members is a module. For example, java.lang.Math is a module.
Another problem with PublicStaticVoidMain is that it allows you to write classes that can be made into objects, but also run as programs.

[The ability to run create classes that can be run as programs is hardly a BadThing, but it would be nicer if one could do so using the object constructor rather than a static method. It'd also be convenient if the runner was a bit smarter about parsing command line arguments into appropriate integers, strings, etc. into the constructor. (or at least had an argument that supported this.)]

No, no, what I meant was that you could have totally unrelated (or only partially related) code in your PublicStaticVoidMain, like this:
	class Complex {
	 public float real, imag;
	 void Complex(float _real = 0, float _imag = 0) {
		real = _real; imag = _imag
	 // add/subtract/mul/div methods not defined because they are not really important to the example.
	 public static void main(String[] args) {
		if (new Complex(1, 1).add(new Complex(-1, -1).equal(0))
		system.exit("Unit test failed.")
All right, I guess, but...bleah.

On the other hand, it clearly distinguishes the special case of launching a program -- for which String[] args exists and may be parsed -- from instantiating a class. The alternative would be to require any "launch-able as program" class to define of a special constructor that accepts, say, a single parameter of Object[] args. That would not be significantly different from public static void main(String[] args), except to force instantiation of an object, which may be pointless overhead if the user has supplied invalid arguments.

That's exactly it. I'd rather just write the code, and I'd rather it not all of it be in classes--some of which have no purpose in instantiation.

[There is more than one such alternative. A bit of reflection could allow parsing command-line arguments based on the types accepted by constructors and methods and such.]

True. Feel free to r/The/An/. It would potentially subject users to a wonderfully unhelpful "No matching constructor or static method found for the supplied arguments" or similar error message, though I suppose the error could be trapped and transformed into something friendlier. And it would benefit from additional syntax to exclude constructors and methods not intended for program launch, but that might inadvertently be invoked by the right combination and/or type of command-line arguments. Oh, and if the users enters 'program 3' at the command-line and there's both 'program(int x)' and 'program(String x)' constructors, which one gets invoked? What if the user enters 'program "3"'? And so on. On the other hand, it makes instantiation within the application homologous to instantiation from outside the application. Dunno... The yuck piles up quickly.

On another hand, PublicStaticVoidMain is extremely easy to extend. I have a project where I need to implement my own launcher (using JNI invokation instead of the good old java.exe). It is easy to add a PublicStaticVoidStop? when it is being run as a SystemService?, a PublicStaticVoidNewInstance? to let it know that a new instance of the software is willing to run with the given arguments, etc... -- PhilippeDetournay

{Is it OK if I delete/edit some of my indignant outbursts? I realize how stupid they sound now...}

No. I enjoyed reading your indignant outbursts. I say leave them in all their (possible) hilarity. And for the record: I HATE the public static void main() method... SO MUCH TYPING FOR SO LITTLE >.< As Churchill might say, "Never before has so much been used to execute so little by so many." Alright probably not, but still.

--An 11th grade AP Computer Science student with no real reasons to post here except code rage.

As a student, you will probably type 'public static void main' far more than you will in a professional career. Many programmers go to retirement never having creating a new application, only working on existing ones. In some shops, starting a new project with 'public static void main' is a landmark event, like the groundbreaking ceremony for a construction project. It might happen very rarely.


View edit of October 21, 2014 or FindPage with title or text search