4

First of all this is NOT an exact duplicate of Initialize final variable before constructor in Java. It is probably related, but there aren't any answers that satisfy me.

My problem is about final variables in Swing GUI's. It's about custom Actions in particular. I have a number of final variables and a number of static final variables.

The question is: if the variable is actually a constant, what is better: initialise them at construction-time, or initialise them at declaration?

The answers on the question I mentionned above generally point towards making the variable static as soon as you are able to assign it when you declare it. That doesn't really make sense to me, as the variables aren't used in a static context. I have a couple of Images that my form uses like icons, I made those static because an Image simply is a static thing unless your application modifies them. That makes sense.

On the other hand, the Actions are new instances of a custom inner class. Very technically they are static too, but it just feels different. They simply mustn't be available in static context imo. So do I put:

private final CustomAction customAction = new CustomAction();

Or do I initialise it in the constructor? Which is better? Or am I thinking the wrong way about static?

Community
  • 1
  • 1
MarioDS
  • 12,895
  • 15
  • 65
  • 121

4 Answers4

5

If the field is a constant, make it a static final member of the class,

public class Foo{
    public static final int BAR = ...;
}

Otherwise, initialize the field in the constructor.

mre
  • 43,520
  • 33
  • 120
  • 170
  • 1
    you are the _n_ th person saying that, though no one ever said why exactly, or justified this approach. – MarioDS Apr 10 '12 at 17:43
  • 1
    @MarioDeSchaepmeester, Please see [this](http://docs.oracle.com/javase/tutorial/java/nutsandbolts/variables.html). – mre Apr 10 '12 at 17:45
  • 4
    @MarioDeSchaepmeester If it's constant why reinitialise it every time you call the constructor? There is _plenty_ of justification, and the link mre posted is a good start. – darrengorman Apr 10 '12 at 17:46
  • @mre Well, that link refined my thoughts on what static really means. Thanks for referring to it. – MarioDS Apr 10 '12 at 18:07
  • @milkplusvellocet, initializing in the constructor allows different constructors to initialize it different values – Steve Kuo Apr 10 '12 at 18:22
  • @SteveKuo Then surely it's not a true constant? – darrengorman Apr 10 '12 at 18:36
  • @mre Okay I just tried to make it static and it doesn't compile, error is "non-static variable this cannot be referenced from a static context". I kinda felt it coming there would be trouble because I instantiate a new object... If I make the class static it works again, but then I would have to make every method my GUI uses static. That can't be right can it? – MarioDS Apr 11 '12 at 09:54
1

Initialize your constant variables at declaration: it is more readable. Make it static if it does not make any sense to put different values into it for different instances of the class, that is, if it is a class level variable, not an instance level.

bpgergo
  • 15,669
  • 5
  • 44
  • 68
1

I think you're on the right track with not making it static, because it sounds like your CustomAction objects are truly custom to the instance of the GUI that creates them in its constructor. I think whether you initialize it in the constructor or not depends on whether your constructor could initialize a CustomAction differently based on the constructor's input arguments.

Where static versus non-static is concerned... a good rule of thumb is, if a variable is going to remain constant across all instances of a particular object type, then that variable should be static. This saves memory over the runtime of your program and also saves CPU time when each object instance is constructed, since that constant won't have to be initialized every time you create a new instance of your Object. On the other hand, if a variable is going to remain constant for a particular instance of an Object, but may be different from instance to instance, then it shouldn't be static.

Finally (pun intended), final should be used whenever you don't want a primitive value or reference to an Object to ever change. The static or non-static context doesn't really influence whether a variable should be final, it's strictly final because the developer doesn't ever want to change that variable. Its static context depends solely on how the developer wants it to be accessed.

CodeBlind
  • 4,519
  • 1
  • 24
  • 36
0

For a fast application startup and program parts the user possibly does not visit (About dialog), static is not good. In general static is not very liked as you did find out. There are some reasons, but nothing very convincing. But sometimes it is a anti-pattern or a sign of it.

Still in your case I would refrain from static images. By the way resources are cached internally.

Joop Eggen
  • 107,315
  • 7
  • 83
  • 138
  • 1
    This is fairly confusing... if your application needs a set of images that remain constant over the runtime of the application (e.g. if I have a toolbar that appears a few times in my application, but contains all the same icons in its buttons), why not load them statically? – CodeBlind Apr 10 '12 at 18:00
  • A toolbar that immediately is visible, yes. Of course it would make no difference here whether static created or on creation of the toolbar. – Joop Eggen Apr 10 '12 at 19:50