Joshua Bloch wrote:When the getField method is invoked for the first time, it reads FieldHolder.field for the first time, causing the FieldHolder class to get initialized. The beauty of this idiom is that the getField method is not synchronized and performs only a field access, so lazy initialization adds practically nothing to the cost of access."
Harry Henriques wrote:Question: The FieldHolder class is a static nested class, so doesn't the class loader load the nested class when the enclosing class is loaded?
Harry Henriques wrote:If the FieldHolder nested class is loaded when the enclosing class is loaded, then why isn't the static FieldType field initialized with an invocation of computeFieldValue( )? Can't we assume that the computeFieldValue( ) method is also a static method? Is this really "Lazy Initialization"? I don't get it?
My Thoughts : http://passion4java.blogspot.com
Try not to become a man of success but rather to become a man of value.
JLS 12.4.1 wrote:A class or interface type T will be initialized immediately before the first occurrence of any one of the following:
* T is a class and an instance of T is created.
* T is a class and a static method declared by T is invoked.
* A static field declared by T is assigned.
* A static field declared by T is used and the field is not a constant variable (§4.12.4).
* T is a top-level class, and an assert statement (§14.10) lexically nested within T is executed.
paraphrase wrote:A class T will be initialized immediately before the first occurrence of the following: T is a class and an instance of T is created.
Henry Wong wrote:
So, there isn't a explicit lock being used, but... internal locks are being used (for the class loading), and it is taking an IO hit too, to load the class. How is this better?
Harry Henriques wrote:What exactly is happening when the getField( ) method accesses the "static" field in the Fieldholder nested class? Is an instance of the FieldHolder nested class created at this time?
Matthew Brown wrote:
Henry Wong wrote:
So, there isn't a explicit lock being used, but... internal locks are being used (for the class loading), and it is taking an IO hit too, to load the class. How is this better?
Presumably the point is that this hit is a one-off, whereas using synchronization affects all calls to the static method. Whether that's worth having a less obvious mechanism is a matter of opinion and the particular situation.
Mike Simmons wrote:No FieldHolder is ever instantiated in this code.
Mike Simmons wrote:since they're static members, you don't need an instance at all to use them, or initialize them. That's pretty much what "static" means when it's used as a modifier for a field or method.
Initialization of a class consists of executing its static initializers and the initializers for static fields (class variables) declared in the class. Initialization of an interface consists of executing the initializers for fields (constants) declared there.
9. Next, execute either the class variable initializers and static initializers of the class, or the field initializers of the interface, in textual order, as though they were a single block, except that final class variables and fields of interfaces whose values are compile-time constants are initialized first (§8.3.2.1, §9.3.1, §13.4.9).