static says that this is the one and only main() method
for this entire class (or program). You can't have
multiple main()s. If you leave this out, you'll get an
error since it could be possible for there to be
multiple instances of main() otherwise.
> one and only main() method...you can't have multiple main()s. public class t {
public static void main(String[] args) { }
public static void main() { }
// why is it the one with the args gets called?
}
Also, that comment leads to the prediction that "If I put static in front of something, I can only have one of it!" (or the converse "If I leave static off, I can have multiples of it") which is false. Avoiding method overloading and making two methods of the same signature, Java will give you a "func() is already defined in t" error regardless of having static or not.>If you leave this out, you'll get an error
public class t {
public void main(String[] args) { }
// and for good measure
public static void main() { }
}
This compiles just fine, however at runtime you'll get the error "Exception in thread "main" java.lang.NoSuchMethodError: main" Very nice for a beginner: "I have a main! It's right there! I have two in fact! ..Oh, it wants the args version.">I teach static from a general standpoint of stating belonging to the class rather than an object of that class. For didactic purposes, sometimes you phrase what-ifs in odd ways to get the point across.
That's a lot better, but now I'm curious, do you go over creating Objects and the keyword "new" in the first day as well? How do you describe the difference between object methods and static class methods without an object to demonstrate? If you try to make an object method in your hello world program:
public class t {
public static void main(String[] args) { hello(); }
public void hello() { System.out.println("Hi"); }
}
you get a helpful "non-static method hello() cannot be referenced from a static context". Of course you can always do "new t().hello();" but..."static" is a complicated keyword, I'm not convinced that saying "You have to have it, treat it like magic for now but we'll cover what it really means later" isn't a fine enough cop-out for HelloWorld.
Perhaps the correct approach with HTML then is to teach XML that happens to render in a browser first, then go on into what makes HTML special. I'm also not convinced that HTML by itself gets very complicated. Sure, bringing in CSS and JavaScript and then dealing with all the issues of different browsers can get as complicated as a Java HelloWorld program, but that's not exactly HelloWorld material for HTML.
I'll agree that young students can handle a lot more complexity than we give them credit for.