Stephen Colebourne schrieb:
Oliver Heger wrote:
The lazy initialization holder class idiom only applies for static
fields of a class. The LazyInitializer class uses the double-check
idiom and is intended for lazy initialization of instance fields. So
there may be different use cases for it.
Maybe this fact can be better emphasized in the documentation and/or
the class name?
The javadoc should have an example of the static field pattern too, as
that is more appropriate for singleton initialisation.
I'm still not sure that this class justifies its place in [lang] though.
It feels like something where inline code (from good online docs) is a
better solution.
Do you think that a generic implementation of the lazy initialization
pattern has such an impact on performance?
In a typical implementation you would add the initializer as a final
member field to a class:
public class MyClass {
private final MyConcreteLazyInitializer init =
new MyConcreteLazyInitializer();
}
The initializer instance has to be created once. Then, on each access to
the object managed by the initializer you have to call init.get()
instead of accessing the volatile field directly.
Perhaps we should run some benchmarks to find out whether this
difference really matters?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
