[lang] LazyInitializer

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[lang] LazyInitializer

jodastephen
I believe that we should remove this class.

The class performs no useful purpose, as there is a better way to use a
separate class to create a value lazily:

// Lazy initialization holder class idiom for static fields
private static class FieldHolder {
      static final FieldType field = computeFieldValue();
}
static FieldType getField() { return FieldHolder.field; }

http://java.sun.com/developer/technicalArticles/Interviews/bloch_effective_08_qa.html

Since LazyInitializer requires the user to create a new instance of a
new class anyway, the benefits of the 'advanced' lazy initializer code
disappear (in fact, its worse, due to the volatile variable requiring a
memory check every time, whereas the regular check above sets a simple
static final.

Any justifications for keeping this?

Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] LazyInitializer

Oliver Heger-3
Stephen Colebourne schrieb:

> I believe that we should remove this class.
>
> The class performs no useful purpose, as there is a better way to use a
> separate class to create a value lazily:
>
> // Lazy initialization holder class idiom for static fields
> private static class FieldHolder {
>      static final FieldType field = computeFieldValue();
> }
> static FieldType getField() { return FieldHolder.field; }
>
> http://java.sun.com/developer/technicalArticles/Interviews/bloch_effective_08_qa.html 
>
>
> Since LazyInitializer requires the user to create a new instance of a
> new class anyway, the benefits of the 'advanced' lazy initializer code
> disappear (in fact, its worse, due to the volatile variable requiring a
> memory check every time, whereas the regular check above sets a simple
> static final.
>
> Any justifications for keeping this?
>

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?

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] LazyInitializer

Stephen Colebourne
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.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] LazyInitializer

Oliver Heger-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] LazyInitializer

Stephen Colebourne
Oliver Heger wrote:

> 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?

Writing benchmarks for this kind of thing would be very difficult I
suspect, and subject to JVM and GC.

One point about this object is that it will be long-lived - the
initializer will live as long as the instance of the parent object. This
will certainly have some GC impact.

Maybe it comes down to a question of whether I personally would use this
approach. I wouldn't, firstly because lazy initialization is so rare,
and secondly because in those cases I'd prefer to inline the code.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]