(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.)
unlikeablePorpo...@gmail.com wrote:
Thanks for your replies. I tried to use a singleton, but for some
reason each attempt to create the singleton from different classes
says the object is null (the second and subsequent calls should say
that the object has been created). Here's the test code:
package org.collector;
public class Collector{
private Collector() {}
private static Collector ref;
public static synchronized Collector getCollectorObject()
{
if(ref == null)
{
System.out.println("ref is null");
ref = new Collector();
}
else
{
System.out.println("ref exists");
}
return ref;
}
}
When I call 'Collector col = Collector.getCollectorObject();' twice in
two different classes, it returns "ref is null". However, if I do this
twice in the same class method, ie
Collector col = Collector.getCollectorObject();
Collector col2 = Collector.getCollectorObject();
I get the expected result:
"ref is null"
"ref exists"
Just to clarify, the Collector singleton is in its own package, and
the methods that have to access it are in different packages.
Am I missing something here? Or is the singleton limited to use one
class or package?
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 visithttp://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.
--
Eric Sosman
esos...@ieee-dot-org.invalid
I think you are right. I am attempting this in two different main()
methods. Damn.