6

Why should I use static initialization block when I can initialize static members through a constructor?

Ajinkya
  • 22,324
  • 33
  • 110
  • 161
Bhushan
  • 354
  • 9
  • 25
  • 9
    What if you _never_ have an instance of that class - but would like to use the static functions of it, which uses the values initialized by the static initializer block? – ppeterka Mar 06 '13 at 11:41
  • 1
    and every time when c'tor is called, static values will be reset. bad!! – Azodious Mar 06 '13 at 11:42

3 Answers3

6

Firstly, you might never have any instances of your class. Or you might want to have the static members iniailized before you have any instances of the class.

Secondly, initializing static members from constructors is more work:

  • you'll need to make sure that every constructor does this;
  • you need to maintain a flag to keep track of whether static members have been initialized;
  • you have to think about synchronization to prevent race conditions;
  • you may have to consider performance implications of the synchronization, especially if you have many threads creating many instances of your class.

Lastly, it's usually the wrong thing to do conceptually (I say "usually" because there are legitimate uses for lazy initialization).

NPE
  • 486,780
  • 108
  • 951
  • 1,012
  • +1 - though if you were going to implement lazy (or non-lazy deferred) initialization, you probably wouldn't "make it happen" in a constructor. – Stephen C Mar 06 '13 at 11:56
1

A static member is not associated to any instance of the class, while the constructor creates an instance. You may use static members without having a single instance of the class, they will still have to be initialized. In this case a constructor can not do the job.

Ivaylo Strandjev
  • 69,226
  • 18
  • 123
  • 176
0

So why:

static Set<String> digits = new HashSet<String>();
static {
    Collections.add(digits, "unu", "du", "tri", "kvar", "kvin");
    digits.add("ses");
    digits.add("sep");
    digits.add("ok");
}

if the following is possible:

static Set<String> digits = new HashSet<String>() {{
    Collections.add(this, "unu", "du", "tri", "kvar", "kvin");
    add("ses");
    add("sep");
    add("ok");
}};
  1. It introduces a new anonymous class, a file in the jar; not so optimal.
  2. The second form is a geeky play thing.
Joop Eggen
  • 107,315
  • 7
  • 83
  • 138
  • why is introducing new anonymous classes not optimal? would it ever lead to classloading bugs? or are you just saying you don't want to bloat your jar. – David T. Dec 15 '13 at 22:45
  • 1
    @DavidT. I have no dislike for either form, but comparing both: the first has redundant occurrences of `digits` and the second creates an anymous class (tiny overhead) and has a misleading syntax for non-java developers. The real danger would be when using a non-static `{{ ... }}` on a Serializable class: then the `this` of the surrounding class get's serialized too. I have encountered such a `X.this` being null after reloading of the object for instance. – Joop Eggen Dec 16 '13 at 00:11
  • 2
    Actually, i found out one difference -> on Eclipse, if you get a crash inside your Anonymous class, Eclipse doesn't even know which project to point the line of crash to (like, say you have a bunch of threads and runnables as anonymous classes) – David T. Dec 16 '13 at 02:08