• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

static member initialization

 
Martin Lira
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Can somebody explain difference between methods to initilize static fields of a class. When is the order of initialization important and which method to prefer if class A is a Java Bean to be invoked from a JSP
class A{
public static String HELLO = �HELLO WORLD�; //declare and initialize
}
class A{
public static String HELLO;
public A(){
HELLO = "HELLO WORLD"; //initialize
}
}
class A{
public static String HELLO;
static{
HELLO = �HELLO WORLD�;
}
}


Thanks,
ML
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your first and third methods are equivalent. The middle one, though, is different and potentially bad, as the static variables will remain uninitialized (i.e., null/0/false) until an object of the class is created.

I generally use option 1; I use option 3 if I am forced to because a constructor needs to be in a try-block.
 
Dan Pollitt
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The middle option would also re-initialize the static variable every time an instance was created, not exactly a massive performance hit at the moment but if this was more work it might be.

Might it leave the static class member in an inconsistent state in a multi-threaded environment, if it was a more complex piece of initialization?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dan Pollitt:
Might it leave the static class member in an inconsistent state in a multi-threaded environment, if it was a more complex piece of initialization?


The second option, using the constructor, can leave the system in an inconsistent state *even in this simple example*. That is, other threads might still see the variable being not or only partly initialized.

Options 1 and 3 are both guaranteed to be thread safe, as far as I know.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Compiled into a static <clinit>.



Just plain wrong.
Also, referencing static members non-statically is fugly.



The same as the first one.

Order is important - initializers are executed in the order that they appear. This is in contrast to C# where order of static initialization is not important. For example, in Java, you will receive a compile-time error for a forward reference to a compile-time constant.
 
Robert Konigsberg
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Question: Why would you want to *do* #2? Also, why would you NOT want HELLO to be final? If it's not final, then what, specifically, are you attempting to do?
 
Martin Lira
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree, theres no problem in the static variable being final.
class A{
public static final String HELLO = �HELLO WORLD� //declare and initialize
}

//ML
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic