«

On 2/4/2013 11:10 PM, Stefan Ram wrote:
> Arne Vajhøj <> writes:
>>> Pattern or anti-pattern, I never encountered a situation where I felt a
>>> need for »singletons«.
>> Other have.
>
> Maybe someone can come up with an SCSE where a singleton is needed.

Runtime.getRuntime().exit(0);

--
Eric Sosman
d

Eric Sosman <> writes:
>>Maybe someone can come up with an SCSE where a singleton is needed.
>Runtime.getRuntime().exit(0);

The library (Java SE) could have been defined to allow:

class Main
{ public static void main( final java.lang.Runtime runtime )
{ runtime.println( runtime.getArgc() + " command-line arguments." );
runtime.exit(); }}

or - with less changes to the current state of Java - to allow:

Runtime.exit( 0 );

On 2/4/13 6:31 PM, Arne Vajhøj wrote:
> On 2/4/2013 11:44 AM, Stefan Ram wrote:
>> Joerg Meier <> writes:
>>> While we are talking about design patterns, you should be aware that
>>> a lot
>>> of people now consider Singletons an antipattern. Your usage of them
>>> certainly sounds like the justly despised "global variable" replacement
>>> many people abuse them for. Might be a good idea to reconsider that
>>> design.
>>
>> Pattern or anti-pattern, I never encountered a situation where I
>> felt a
>> need for »singletons«.
>
> Other have.
>
> GoF has it.
>
> Spring has had it since 1.x.
>
> EJB got it in 3.1.
>
> Implementations and usage are very different, but the idea of
> everybody using the same object is the same.
>
> Arne

I think the real anti-pattern is the common implementation of how to get
the value of the singleton. Singleton's are useful, but when the
singleton status of an object is enforced beyond reason, you end up with
with all kinds of "work-arounds" to the fact that the object is a
singleton. Dependency Injection can help alleviate some of those
problems, by making the singleton nature of the object a consequence of
it only being instantiated by the framework, rather than by the class
itself being a "singleton class".

On 2/5/2013 12:51 PM, Stefan Ram wrote:
> Eric Sosman <> writes:
>>> Maybe someone can come up with an SCSE where a singleton is needed.
>> Runtime.getRuntime().exit(0);
>
> The library (Java SE) could have been defined to allow:
>
> class Main
> { public static void main( final java.lang.Runtime runtime )
> { runtime.println( runtime.getArgc() + " command-line arguments." );
> runtime.exit(); }}
>
> or - with less changes to the current state of Java - to allow:
>
> Runtime.exit( 0 );

A singleton class can be transformed into an uninstantiable
class having only static methods. An uninstantiable class with
only static methods can be transformed into a singleton class.
The two designs are duals: Why should one be deprecated and the
other preferred?

If all-static vs. singleton is the most pressing problem
someone faces, he has an easy life indeed!

--
Eric Sosman
d

Eric Sosman <> writes:
>A singleton class can be transformed into an uninstantiable
>class having only static methods.

Static methods cannot be passed via reference or used to
implement interfaces. Therefore, there is a need for
non-static methods sometimes. But this does not mean a
singleton, I am thinking of a POJO first and foremost
until someone shows me where a POJO does not suffices,
but a singleton is needed.

lipska the kat wrote:
> OK, I know I'm probably still being ignored because I've upset some
> people but can someone please explain to me exactly what a 'static
> class' is (WRT Java of course)

RTFM:
http://docs.oracle.com/javase/specs/...html#jls-8.5.1

The original statement was inaccurate, as you point out.

What he meant must have been something like "except for static methods, which cannot
implement an interface".

I also made an inaccurate statement on this matter, as your example shows.

--
Lew

Stefan Ram wrote:
> Eric Sosman writes:
>> A singleton class can be transformed into an uninstantiable
>> class having only static methods.
>
> Static methods cannot be passed via reference or used to

Do you mean "via a reference to their owning instance"?

> implement interfaces. Therefore, there is a need for
> non-static methods sometimes. But this does not mean a
> singleton, I am thinking of a POJO first and foremost
> until someone shows me where a POJO does not suffices,
> but a singleton is needed.

Most of the time, at least, it suffices to have only one instance of a class where
otherwise one might be tempted to implement a Singleton.

I have a strong bias toward using instance methods over static methods, in part because
they can implement an interface method. It does not suffice that the method merely
doesn't access instance state. It also needs to be "global" by design.

Instance methods can be easier to control in multi-threaded contexts. It's often good to
have a manager instance that controls the methods so that different units can use them
independently.

If you later decide that "singleton" was a mistake, instance methods don't need to be
refactored.

There's also a circular analysis where type state is maintained in mutable static variables, so one
creates static methods on the theory that they don't access instance state.

The risk of mistake with instance methods is lower than with static methods.

So if I have a compelling argument for making a method static, fine, but tie or a close second
goes to the instance implementation.

--
Lew

On 2/5/2013 1:43 AM, lipska the kat wrote:

> OK, I know I'm probably still being ignored because I've upset some
> people but can someone please explain to me exactly what a 'static
> class' is (WRT Java of course)


Part of the reason I'm generally ignoring your posts is that you don't
look obvious stuff up with Google. If you had said "I searched for
'static Java class' but didn't really understand the results," that
would a bit different. But at least trying to look stuff up is pretty
basic.

That said, I think people are using the term loosely and expecting the
reader to fill in the gaps. A real static class is a nested class that
has no (implied) reference to its enclosing instance.

<http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html>

What's being referred to up-thread is just a class with all static
methods which also has no public constructor. (I think, I'm not really
reading this discussion closely.) It's a standard pattern in Java which
is used to make "utility classes." c.f. java.lang.Math, which does
exactly this.

The standard pattern is:

public class UsefulUtils {
private UsefulUtils() {}

... public static methods here

}

This class is effectively final because without a public ctor it cannot
be extended. If this class is stateless or has no mutable state, then
it is also thread safe, absent some other use of globals.

markspace <> writes:
>A real static class is a nested class

>that has

whose instances have

>no (implied) reference to

>its enclosing instance.

their enclosing instances.

BTW: A static class has a reference to its enclosing class.

public class Main
{ static class C {}
public static void main( final java.lang.String args[] )
{ java.lang.System.out.println( C.class.getEnclosingClass() ); }}

On 2/5/2013 2:06 PM, Stefan Ram wrote:
> markspace <> writes:
>> A real static class is a nested class
>
>> that has
>
> whose instances have
>
>> no (implied) reference to
>
>> its enclosing instance.
>
> their enclosing instances.
>
> BTW: A static class has a reference to its enclosing class.


"Class object." It's splitting hairs a bit, but that is how the JLS
refers to them.

Example:

"In the Java virtual machine, every object belongs to some particular
class: the class that was mentioned in the creation expression that
produced the object (§15.9), or the class whose Class object was used to
invoke a reflective method to produce the object..."

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.6>


>
> public class Main
> { static class C {}
> public static void main( final java.lang.String args[] )
> { java.lang.System.out.println( C.class.getEnclosingClass() ); }}
>

C.class is a class object. "Class" as I use it above (usually with a
lower case 'c') is more the concept of a class, rather than its Java
implementation of the class. (Rather the same way that the JLS uses
'class' to refer to the general concept of a class in OOD, for example
that section of the JLS I quoted above.)

That said, you're not really wrong to point out it's really the
instances that have references to their enclosing class.