Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #37897 > unrolled thread

Guice vs plain singleton

Back to article view | Back to comp.lang.java.programmer

Contents

  Guice vs plain singleton Victor Porton <porton@narod.ru> - 2017-12-20 18:19 +0200
    Re: Guice vs plain singleton Patrick Roemer <sangamon@netcologne.de> - 2017-12-20 17:53 +0100
      Re: Guice vs plain singleton Daniele Futtorovic <da.futt.news@laposte.net> - 2017-12-21 13:59 +0100
        Re: Guice vs plain singleton lewbloch@gmail.com - 2017-12-21 11:36 -0800
          Re: Guice vs plain singleton Arne Vajhøj <arne@vajhoej.dk> - 2017-12-22 20:11 -0500
            Re: Guice vs plain singleton Sebastian <nowhere@nirvana.org> - 2017-12-23 16:15 +0100
              Re: Guice vs plain singleton lewbloch@gmail.com - 2017-12-23 09:54 -0800
                Re: Guice vs plain singleton Arne Vajhøj <arne@vajhoej.dk> - 2017-12-23 19:27 -0500

#37897 — Guice vs plain singleton

What should I prefer for creating a singleton object with "heavy" (requiring 
much CPU time or like this) constructor:

- Guice @Singleton injector

or 

- plain hand-made singleton like 

static Type instance; ... if(instance==null) ...

?

-- 
Victor Porton - http://portonvictor.org

[toc] | [next] | [standalone]

#37898

Responding to Victor Porton:
> What should I prefer for creating a singleton object with "heavy" (requiring 
> much CPU time or like this) constructor:
> 
> - Guice @Singleton injector
> 
> or 
> 
> - plain hand-made singleton like 
> 
> static Type instance; ... if(instance==null) ...
> 
> ?

public class Singleton {
  public final static Singleton INSTANCE = new Singleton();

  private Singleton() {
    // expensive setup
  }

  public Foo service(Bar bar) {
    // ...
  }
}

The instance will only be created when the class is initialized, and
that's only if a client accesses the field or calls the method on this
class (which requires having access to the instance first). So as long
as you don't provide any unrelated functionality on this class that
might unadvertently trigger class initialization, you'll get lazy on
demand initialization for free with this pattern, without having to
worry about synchronization issues or involving 3rd party code.

I'd be reluctant to use a singleton at all in the first place, though.

Best regards,
Patrick

[toc] | [prev] | [next] | [standalone]

#37900

On 2017-12-20 17:53, Patrick Roemer wrote:
> Responding to Victor Porton:
>> What should I prefer for creating a singleton object with "heavy" (requiring 
>> much CPU time or like this) constructor:
>>
>> - Guice @Singleton injector
>>
>> or 
>>
>> - plain hand-made singleton like 
>>
>> static Type instance; ... if(instance==null) ...
>>
>> ?
> 
> public class Singleton {
>   public final static Singleton INSTANCE = new Singleton();
> 
>   private Singleton() {
>     // expensive setup
>   }
> 
>   public Foo service(Bar bar) {
>     // ...
>   }
> }
> 
> The instance will only be created when the class is initialized, and
> that's only if a client accesses the field or calls the method on this
> class (which requires having access to the instance first). 

More precisely:
<https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4.1>.

See also:
<https://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom>

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#37902

On Thursday, December 21, 2017 at 5:00:45 AM UTC-8, Daniele Futtorovic wrote:
> On 2017-12-20 17:53, Patrick Roemer wrote:
> > Responding to Victor Porton:
> >> What should I prefer for creating a singleton object with "heavy" (requiring 
> >> much CPU time or like this) constructor:
> >>
> >> - Guice @Singleton injector
> >>
> >> or 
> >>
> >> - plain hand-made singleton like 
> >>
> >> static Type instance; ... if(instance==null) ...
> >>
> >> ?

public enum Singletary
{
  INSTANCE;

  // constructor, methods, ...
}

This has been solved and published since, oh, 2008, when the second edition of _Effective Java_ came out.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#37905

On 12/21/2017 2:36 PM, lewbloch@gmail.com wrote:
> On Thursday, December 21, 2017 at 5:00:45 AM UTC-8, Daniele Futtorovic wrote:
>> On 2017-12-20 17:53, Patrick Roemer wrote:
>>> Responding to Victor Porton:
>>>> What should I prefer for creating a singleton object with "heavy" (requiring
>>>> much CPU time or like this) constructor:
>>>>
>>>> - Guice @Singleton injector
>>>>
>>>> or
>>>>
>>>> - plain hand-made singleton like
>>>>
>>>> static Type instance; ... if(instance==null) ...
>>>>
>>>> ?
> 
> public enum Singletary
> {
>    INSTANCE;
> 
>    // constructor, methods, ...
> }
> 
> This has been solved and published since, oh, 2008, when the second edition of _Effective Java_ came out.

It is certainly the most smart way from a Java technology point of view.
Significant less code than the alternatives.

But even with all due respect to the other Bloch then I do not
consider it good code.

It is using some very Java specific characteristics of an enumeration
to provide some functionality that is not related to being an
enumeration.

Arne

[toc] | [prev] | [next] | [standalone]

#37906

Am 23.12.2017 um 02:11 schrieb Arne Vajhøj:
> On 12/21/2017 2:36 PM, lewbloch@gmail.com wrote:
>> On Thursday, December 21, 2017 at 5:00:45 AM UTC-8, Daniele Futtorovic
>> wrote:
>>> On 2017-12-20 17:53, Patrick Roemer wrote:
>>>> Responding to Victor Porton:
>>>>> What should I prefer for creating a singleton object with "heavy"
>>>>> (requiring
>>>>> much CPU time or like this) constructor:
>>>>>
>>>>> - Guice @Singleton injector
>>>>>
>>>>> or
>>>>>
>>>>> - plain hand-made singleton like
>>>>>
>>>>> static Type instance; ... if(instance==null) ...
>>>>>
>>>>> ?
>>
>> public enum Singletary
>> {
>>    INSTANCE;
>>
>>    // constructor, methods, ...
>> }
>>
>> This has been solved and published since, oh, 2008, when the second
>> edition of _Effective Java_ came out.
>
> It is certainly the most smart way from a Java technology point of view.
> Significant less code than the alternatives.
>
> But even with all due respect to the other Bloch then I do not
> consider it good code.
>
> It is using some very Java specific characteristics of an enumeration
> to provide some functionality that is not related to being an
> enumeration.
>
> Arne

I agree with Arne. Here's a Stackoverflow answer discussing some of the 
drawbacks of this approach: 
https://softwareengineering.stackexchange.com/a/179392
-- Sebastian

[toc] | [prev] | [next] | [standalone]

#37907

While it's true that some inherited methods from `Enum` are superfluous for singletons, most of the argument against using enums for singletons derive from undocumented and idiosyncratic assumptions about what an enum "should" be. For example, citing enums' serialization mechanism as an contraindicator is a red herring.

The fact is that a hand-rolled singleton type requires great care to protect against things like serialization mistakes that enums solve for free. Given how badly every single Java candidate I've interviewed did at implementing singletons, I'd much rather have a few superfluous methods than a crappy implementation. 

There's absolutely nothing in the idea of an enum to dissuade one from having only one enum constant, contrary to the argument presented. Yes, enum doesn't solve every possible problem, so you might occasionally want to roll your own. But the advantages of enums for singletons are so strong, and the risk of the custom approach is high enough, that enums should be the first and usually the last approach to consider.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#37908

On 12/23/2017 12:54 PM, lewbloch@gmail.com wrote:
> While it's true that some inherited methods from `Enum` are
> superfluous for singletons, most of the argument against using enums
> for singletons derive from undocumented and idiosyncratic assumptions
> about what an enum "should" be. For example, citing enums'
> serialization mechanism as an contraindicator is a red herring.
> 
> The fact is that a hand-rolled singleton type requires great care to
> protect against things like serialization mistakes that enums solve
> for free. Given how badly every single Java candidate I've
> interviewed did at implementing singletons, I'd much rather have a
> few superfluous methods than a crappy implementation.
> 
> There's absolutely nothing in the idea of an enum to dissuade one
> from having only one enum constant, contrary to the argument
> presented. Yes, enum doesn't solve every possible problem, so you
> might occasionally want to roll your own. But the advantages of enums
> for singletons are so strong, and the risk of the custom approach is
> high enough, that enums should be the first and usually the last
> approach to consider.


It depends on what evaluation criteria is used.

If one want to minimize lines of code then it is a
fine solution.

If one want to write nice readable code following
OOP principles then it is a bad solution.

A singleton is not an enumeration and making it
one to save lines of code for making it thread safe
is not how one should write code. One should use
enum for types that are actual enumerations.

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web