Originally posted by Manoj KG: I am also wondering why Java didn't allow us to make classes static.
For an eg I believe Math class should be an ideal candidate for this. I don't see any scenario where Math class should be instantiated(Unless we want to call any method of Object from the instance).
First, static has a different meaning for member classes -- see my previous reply. Second, Java already has a way to stop a class from being instantiated by clients, and java.lang.Math is taking advantage of it: make its constructors private.
We don't need a constructor for Math. But in Java all classes have constructors. If we don't provide one ourselves, a public constructor is implicitly created for us. We don't want that for Math; instead we have a private constructor as the standard way of making a class uninstantiable under most circumstances.
Originally posted by Shrinivas Mujumdar: Hello Friends, Thanks for your keen intrest in this topic.....but i think question still remains the same.
To get to a satisfactory answer, let's do this. Can you describe here what you understand by the term "static". Based on that, we can narrow in why outer classes can't be static. [ January 09, 2006: Message edited by: Stuart Ash ]
To the Math-like example: it would have been possible to have "static" as a modifier for classes that means all methods must be static. The inventors apparently didn't think that's what "static" meant so they didn't do that. [ January 09, 2006: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
1. Should be common to all objects of the class.
2. Should belong to the class and accessible by class name.
3. Should not need an object of class to access them.
Now suppose we are defining an outer class as static and suppose we are allowed to do so. Will this serve any purpose or provide any advantage to a developer or it will create ambiguity and complications for both developers and language creators?
Let’s check, defining an outer class as static will serve purposes which we have defined above or not?
1. Every class is already common to all of its objects and there is no need to make it static to become available to all of its objects.
2. We need a class name to access its static members because these members are part of class while an outer class is part of package and we can directly access the class by just writing package_name.class_name (similar to class_name.static_field_name), So again there is no need to do which is already there by default.
3. We do not need any object to access a class if it is visible, we can simply write package_name.class_name to access it. And by definition, a class is a blueprint for its objects and we create a class to create objects from it (exception will always be there e.g. java.lang.Math), again there is no need to define an outer class as static.
From above points, we can say Java creators had not allowed an outer class to be static because there is no need to make it static. Allowing to make the outer class static will only increase complications, ambiguity and duplicity. Read more on Why An Outer Java Class Can’t Be Static
We begin by testing your absorbancy by exposing you to this tiny ad:
SKIP - a book about connecting industrious people with elderly land owners