Re: Q: Atomicity of class loading
Daniel Pitts wrote:
Eric Sosman wrote:
Daniel Pitts wrote:
G. Ralph Kuntz, MD wrote:
Is class loading and class variable initialization atomic?
If I have a class defined as follows:
public class X {
private static final X INSTANCE = new X();
private X() {}
public static X getInstance() {
return INSTANCE;
}
}
can I be sure that when the class loads as a result of the call
X.getInstance(),only one instance will be created?
The short answer is no.
Two different class loaders might load the class X at different times.
And in that case you would end up with more than one instance.
But they will be of different classes that happen to share
a single name. Try it: load X twice with two class loaders, call
both getInstance methods, call getClass on each of the instances,
and compare the Class objects.
A better approach would be to use dependency injection (a form of
inversion of control). Create the instance at initialization time in
the main method, for example), and pass it where it is needed.
In the presence of multiple class loaders, I don't see why
this would change anything. Also, I don't see why one would
saddle every class that wants to use X with the job of writing
X's initialization code.
--
Eric Sosman
esosman@acm-dot-org.invalid
class X loaded by classloader A would indeed be "different" then classX
loaded by classloader B, however, the question was about the number of
possible instances in the VM, and I was pointing out how it is possible
to not be unique.
One need not introduce multiple class loaders to get this
kind of "non-uniqueness." I can create an org.esosman.Runtime
and a com.dpitts.System even though both java.lang.Runtime and
java.lang.System are singletons. In this case the coincidence
of names is disambiguated by the package; that seems to me no
different that the coincidence of "full names" being disambiguated
by class loader.
The X loaded by ClassLoader A is not the same class as the
X loaded by ClassLoader B, even if they have the same package
names and the same byte code. They are different classes, so
the existence of B's X instance does not render A's X instance
non-unique, not any more than org.esosman.Runtime threatens the
uniqueness of java.lang.Runtime.
I think you missed the point.
That's possible, of course. But I think *you* have missed
the point that two classes with identical names when loaded by
different class loaders are different classes altogether. I
haven't checked, but I'm confident that a reference to A's X
is not assignment-compatible with B's X. Try to convert either
to the other, and I think you'll get ClassCastException -- and
if an Xa can't be cast to an Xb, how can these two incompatible
entities possibly be considered duplicates?
Only one class is responsible for initializing the X instance. the X
class itself. And only one class (or layer, depending on how you view
it) is responsible for creating the single X instance.. The
responsible layer is the framework. Or, at the very least, the
framework could create a thread-safe singleton factory object.
You've shifted from "the main method, for example" to "the
framework," and somewhere along the way you've exceeded my
capacity to understand. You may be right or wrong or undecidable,
but I can't tell: I don't know what you're saying here.
--
Eric Sosman
esosman@acm-dot-org.invalid