The first Java-Program a programmer encounters:

public class Main
{ public static void main( final java.lang.String[] args )
 { java.lang.System.out.println( "Hello world!" ); }}

 uses a static variable »out«.

 To avoid it, we might need a new Java with:

public class Main
{ public static void main( final System system )
 { system.out.println( "Hello world!" ); }}

 Then, »system« needs to be passed to many methods and
 constructors, whereever it possibly might be needed.

 An example would be the getter:

java.lang.Thread.currentThread()

 It is not the same as a singleton, because there is no
 intention that the result is the /only/ instance of its
 class.

 To avoid it, we'd need to pass another object, because,
 logically, the current thread is not a system property.

public class Main
{ public static void main( final System system, final Thread currentThread )
 { system.out.println( "Hello world!" ); }}

 This also would have to be passed to every method that
 possibly might need it some day or otherwise many signatures
 will need to change in order to add it as a parameter.

Simply to avoid top-posting will indicate thanks.

Are you an org, named "collector"?

The org domain implies non-profit organizations.

Since everything in Java is an object, having "Object" in your method name is
redundant.

This is overuse of lazy initialization.

Just establish the object in the class initializer.

I don't know exactly why this happens, but I bet you'll get rid of the problem
altogether like this

public class Collector
{
  private Collector()
  {
  }
  private static final Collector UNIQUE = new Collector();
  // this has the advantage of making the variable non-replaceable
  // and eliminating the need for synchronization

  public static Collector getCollector()
  {
    return UNIQUE;
  }
}

(Please position a reply after the message you're replying
to, or interspersed with it for a point-by-point reply.
Backward things read to harder it's.)

    With the code as you've shown it, I don't understand how
the behavior you report can occur.  Is the Collector class
truly as lightweight as shown?  Or have you deleted other bits
of code for brevity's sake?  That's usually a good idea, but
you may have omitted something important -- for instance, a
method that accesses `ref' while synchronizing on something
other than Collector.class, or not synchronizing at all.

    As for the interaction of package membership and singletons:
There is none.  The package forms part of the complete name of
a class (it's org.collector.Collector, not just Collector), and
package membership affects the reach of some access levels (but
not public and not private).  Package membership has nothing to
do with whether `ref' is or isn't null, nor with what the method
synchronizes on, nor with how many times the constructor is used.

    Perhaps the secret lies in how you call the method "twice in
two different classes:" if you run one class' main method and let
the program finish, and then run the other class' main method and
let its program finish, these executions are in two different
universes, separated by a Big Crunch and a Big Bang.  Nothing that
happened in one execution (aside from modifying persistent storage
like a file system) affects what happens in the other.  When the
second program runs, the Collector class is loaded anew -- it is
in this sense a "different" Collector class -- and the singleton
that existed in the first program is long gone.  The second program
will then create a new singleton Collector.

    If you need a singleton that persists across different JVM
instances, you'll need to work harder.  It's doable (I think; I
haven't done it myself), but takes you into the arena of object
serialization and of debates about what "the same" means across
what amounts to a reboot.

    By the way, you can visit http://www.collector.org/ to learn
that there's an organization out there who might distribute Java
code of their own.  If they do, their package names will begin
with org.collector, and there will be confusion and perhaps bad
consequences if someone tries to use your code and their code in
the same program.  Unless you're part of collector.org, you should
probably choose another package name.

On Aug 18, 10:42 pm, unlikeablePorpo...@gmail.com wrote:

IMHO it's ok, since it ptints to System.out message from block with
lazy initialization,
it does not return null, does it?

        private Collector() {}
        private static Collector ref;

        public static synchronized Collector getCollectorObject()
        {
                if(ref == null)
                {
                         System.out.println("lazy initialization!
here, IMHO static will be better...");
                        ref = new Collector();
                }
                else
                {
                        System.out.println("ref exists");
                }

                return ref;//does not return null object in any case!
        }
(first time will print to System.out "lazy initialization! here...")
And yes, removing lazy initialization will make class more concurrent-
compatible.

Good Luck, Theme