Constants: "final static" vs. "final"
In a GUI object, I have some class constants that are only used internally. Example 1:
privatefinalint PREFERRED_WIDTH = MainWin.MAX_WINDOW_WIDTH;
privatefinalint PREFERRED_HEIGHT = 50;
Example 2:
privatefinal JButton helpButton =new JButton("Help");
privatefinal JButton closeButton =new JButton("Close");
privatefinal JLabel clearanceLabel = createClearanceLabel();
Should the members in EX1, EX2 be static?
These items are members of a GUI object, and there is only 1 instance of this GUI object during application runtime.
The nature of my question is about the best practices of when to use the "static" modifier for private class constants.
Thank you
Message was edited by:
PatrickFinnigan
Since you'll only create one instance of the class, offhand I can't see of any pressing reason to make them static.
But there is a good reason: it's a common idiom to define constants by making them static and final. By not making them static, your code is a little less obvious to people reading it.
Example 1, yes (probably) because they are fixed values that you can always use anywhere. As mentioned, this is the common way. But I probably would either make them private non-final, or protected static final (for subclasses).
Example 2, I probably would not make them final either. Maybe someone has some reasons (optimization, etc.) for doing that, but they are private anyway, so you don't have to worry about some other code changing them outside of your class... which you already know what your class is doing.
I guess the static final stuff gets optimized sometimes by compilers, though.
Thank you for the feedback.
I still do not understand Java best practices for when to use the "final" and "static" modifiers on private member variables.
I was of the mindset to use "final" as often as possible and "static" as sparingly as possible -- is this the correct mindset?
1.) Should I make constants, such as a window's width, "private static final" in almost every situation?
2.) Should private members, such as buttons and labels, be "final" if they are not modified after initialization?
3.) Should private members, such as buttons and labels, be "static" if they are not modified after initialization?
4.) Is there a preference on whether the order of modifiers should go "final static" or "static final"? This is trivial, but I want my code to be consistent.
There's a rule for when you make variables static: "Do I need an instance of this variable for each object I create, or will one instance for the entire class be sufficient?"
In this case, since the variable is a constant, then one instance for the entire class is sufficient. So make it static.
I have also read the rule:
"Never declare a static variable when a class variable will suffice."
These two rules seem to be in contention. However, I like your rule better, and your explanation is very clear. Thanks.
> I was of the mindset to use "final" as often as
> possible and "static" as sparingly as possible -- is
> this the correct mindset?
Generally, I'd say yes.
> 1.) Should I make constants, such as a window's
> width, "private static final" in almost every
> situation?
Well, I'm wondering why you need a whole separate class for this. You're going to have multiple windows normally, right? So wouldn't you have multiple instances of a "window size" class?
> 2.) Should private members, such as buttons and
> labels, be "final" if they are not modified after
> initialization?
Yes.
> 3.) Should private members, such as buttons and
> labels, be "static" if they are not modified after
> initialization?
Sometimes, but usually not.
> 4.) Is there a preference on whether the order of
> modifiers should go "final static" or "static final"?
> This is trivial, but I want my code to be consistent.
No idea.
static variables are allocated when the class is loaded. static refers to a method or variable that is not attached to a particular object, but rather to the class as a whole.
so for constants its better to add static modifier
Static variables are used to express properties of the class, not of individual instances. The fact that there is only one instance of the class has nothing to do with whether or not to use static.
So I'd say that the properties in example 1 should be static as they represent properties of the class, and the properties in example 2 should not as they are specific to one instance. If there were 2 instances of this class, both would need separate instances of these subcomponents, so static is inappropriate.
Final is appropriate if the value (basic type or reference) should never change.
"static" garuntees that across all instances of an object, the variable in question is the same. Final does not do this. consider the following:
class Test {
private final int NOT_A_CONSTANT; // Ok
private static final int NOT_A_CONSTANT_TWO; // Error !
public Test(int x) {
NOT_A_CONSTANT = x; // This works
NOT_A_CONSTANT_TWO = x; // You can't do this!
}
}
The first is acceptable; a final variable can be defined in the constructor instead of inline. this means that each instance could potentially have a different value.
NOT_A_CONSTANT_TWO, however, will throw an exception if you do not declare its value immediately. Furthermore, it can NOT be given a value in the constructor.
If your class implements the singleton pattern, it doesn't matter. It is just a matter of good practice; if you want to make sure that a variable will NEVER change value, the best way to absolutely ensure a variable's value is to make it static and final.
Message was edited by:
jGardner
> 3.) Should private members, such as buttons and
> labels, be "static" if they are not modified after
> initialization?
No (generally). First, the static-ness and non-modified-ness of said members are not connected. You can modify non-final static fields.
For UI components, I'd say no to static, on the grounds that you are excluding the possibility of using multiple instances of the same component...
public class MyComp extends JPanel
{
private JTextField field = new ...;
private JButton button = new ...;
}
I'd say no static there, because if they were, you could not create 2 MyComp instances. Only 1 text field and button would exist, and they can't be in 2 different parent components at the same time.
Thanks for all replies, this is becoming more clear.
Q: say I am running two instances of the same application concurrently (I have two main windows up). Are static members shared among object instances only on a per-application basis, or are they shared between applications too?
> Q: say I am running two instances of the same
> application concurrently (I have two main windows
> up). Are static members shared among object
> instances only on a per-application basis, or are
> they shared between applications too?
Different instances of the application run on different JVMs as different processes. Static variables get stored in process heap and so will not be shared among applications.
> I was of the mindset to use "final" as often as
> possible
Yepp.
> and "static" as sparingly as possible --
Disagreement here. First, of course, use it when appropriate. Second, though, my customers coding guidelines urge to use static for all methods that aren't accessing non-static members; there might be a reason for that although I don't know. But it's basically no problem declaring those as static. With other members you usually don'thave a choice. Constants always static - why have more than one set of them?
> 1.) Should I make constants, such as a window's
> width, "private static final" in almost every
> situation?
Why not?
> 2.) Should private members, such as buttons and
> labels, be "final" if they are not modified after
> initialization?
Yes.
> 3.) Should private members, such as buttons and
> labels, be "static" if they are not modified after
> initialization?
No, because they're probably instance attributes; static would make no sense.
> 4.) Is there a preference on whether the order of
> modifiers should go "final static" or "static final"?
> This is trivial, but I want my code to be consistent.
The preference is always specified by the person you write the code for.
> > and "static" as sparingly as possible --
>
> Disagreement here. First, of course, use it when
> appropriate. Second, though, my customers coding
> guidelines urge to use static for all methods that
> aren't accessing non-static members; there might be a
> reason for that although I don't know. But it's
> basically no problem declaring those as static.
I can see the logic of declaring them static if they don't access anything instance-level; at least it makes it more obvious what it's doing. I suppose you might want to keep it non-static if you think that at some point the implementation will change and you don't want users of the API locked into a way of calling it which won't work, but such thinking can be dangerous.
On a related note, a bad design choice I sometimes see is an excessive use of objects in which there is absolutely no state being maintained; the code in question doesn't need to be non-static at all. Making things objects when they don't have to be can make things too complicated.
On the other hand, when you're doing object-oriented programming and you find that you're never creating objects, then something is seriously wrong.
I think the best rule of thumb is: keep a clear understanding of what's an object, what isn't, and why; keep objects and non-objects clearly built as such, don't make things that are basically static utility methods into objects just because you can; and if you find that you're throwing the keyword "static" around a lot, then it's a red flag that you've probably got something wrong in your design.
