static modifier is usually used for class members to determine if the member is created during class loading or during instantiation. I am not sure about what sort of behavior are you expecteing by making the top-level class as'static'. Could you elaborate?
I think you should look into the Singleton pattern. That allows you to have only one instance of a class; similar to having only one "instance" of a static variable within a class. This is, as I understand it, what you are looking for. [ May 29, 2007: Message edited by: Andris Jekabsons ]
I read in books and I hear fellow developers say: "The Math class is static".
What they mean is that every method in the Math class is a static method. Such as:
int x = Math.abs(-1);
Here, the abs() method is static because it doesn't require an instance of the Math class to be invoked.
Also, all of the variables of the Math class are also static. Such as the constant PI:
double d = Math.PI;
I don't understand why you can't make a top-level class static:
I think that a "static final class", one that cannot possibly be instantiated, would merely be as easy as using the final and the static keywords. But you can't use the static keyword on a top-level class. You have to know the "secret handshake" of declaring a private constructor with no arguments. This is not intuitive.
The second part of my question is that for inner classes, you don't have to use the static keyword, but it is recommended that you "favor" the use of the static keyword for an inner class.
I read a little further in "Effective Java" 1st edition and it says that an inner class (aka a member class or a nested class) should be declared static to declare that the inner class can't possibly access variables of the outer class.
This may not be on the SCJP exam, but I remember things if they make sense to me.
Why to declare an inner class as static makes sense to me now. It is just a special case of restricting access, similiar to using private and protected in place of public, but declaring a Utility class is so hard, I don't know.
I understand that by using a private constrructor and a static factory method, you can implement the Singleton design pattern.
I was trying to declare a Utility Fascade design pattern. Credit to the book: "Design Patterns In Java", by Metsker and Wake.
By the way, I don't think that design patters are covered on the SCJP. I'm just trying to understand the Java language so that I remember things better.
[ May 29, 2007: Message edited by: Kaydell Leavitt ]
Because the topic is discussing a language design issue rather than an SCJP one, I'll move this to our Java In General (INTERMEDIATE) forum. Of course, interested SCJPers may join in the discussion there, if they want.
To reiterate in other words: a static inner class is *not* - I repeat: *not* - a class of which all members are static.
Consequently, saying that the Math class "is static" is at least confusing, if not plain incorrect.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
If there was to be a set of modifiers for a class that meant it could not be instantiated and could only contain static methods, that set would be "abstract final", wouldn't it?
Abstract means you cannot directly instantiate the class (only a subclass). Final means you cannot subclass the class. Therefore, the combination would mean you can never instantiate the class in any way.
I'd have liked to see this as legal. Java's designers chose not to make it so. They may not have realised what "abstract final" might be useful for. Or they may have been only too aware of it, but wanted to discourage such classes: uninstantiable classes of static methods are usually poor OO design.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
[Kaydell]: Maybe the problem is that everyone says that the Math class is a "static" class.
Yes. I haven't noticed "everyone" doing it. But anyone who does, they're being sloppy. "Utility" classes is a pretty good alternate; classes of static methods are often named things like FooUtil or FooUtils.
I also feel compelled to point out that an inner class is, by definition (for Java), not static. Anyone referring to a "static inner class" should be assumed to mean a static nested class. Nested classes are either static or inner, not both. Despite they way they are described by some books and people (some of them, from Sun).
This may seem a nit-picky point, but it's important to understand if you're reading the language specification, or statements by other people who are using language consistent with the JLS. If someone says, for example, that an inner class may not declare a static method, that's true. But that statement does not apply to static nested classes. And sloppy use of the term "inner class" just creates confusion. It's understandable, given Sun's sometimes-poor presentation of this topic in the past (and frankly I think it was a poor choice for them to define the term this way). But still, I prefer to stick to the official definition for clarity. [ May 29, 2007: Message edited by: Jim Yingst ]
I think that I'll start calling the Math class (and those like the Math class) "Utility" classes, using the word "Utility" from design pattern books.
"Uninstantiable" is another word people have used for such classes.,
As far as the realization about "static" nested classes being a form of access control: no, not really. A static nested class, given an instance of the outer class, can access its private instance members, as it is within the scope of the parent class. The reason it "can't" access the outer class's instance members is that for a static nested class, there's no implicit associated instance of the enclosing class, whereas for a non-static one, there is.