When does a class REALLY become object?

[Jim Francis]

Hi. Newbie to the ranch, here.
The question has been debated in a Java course I'm taking.
Having some OO experience, I think that a class becomes an object only when it is "instantiated", and that instantiation occurs when "new" is used (in general, not primitive, not String).
Someone argued that for each "loaded" class, there is an object of type Class. So, in his opinion, a loaded class (instantiated or not) is an object by virtue of the Class object (he considers this a meta-class of all classes).
This seems strange to me. The class of type Class (or an object of type Class) seems to me to belong to the JVM and not my app. I picture the JVM using the Class objects as a directory of loaded classes. It just so happens that the JVM kindly provides public static access to some of it's information.
So, am I right or not?
Can I still say that a class does not become and object until it is instantiated? And "instantiated" is also defined to me as having had its constructor executed.
Thanks. Appreciate your thoughts.
[ September 20, 2003: Message edited by: Jim Francis ]

[Gary Mann]

1. I agree with you. An object of type "MyClass" only exists once it's been instantiated. The fact there there may be an associated object of type "Class" doesn't mean that "MyClass" exists.
2. IMHO, debates like this can be interesting, but are largely irrelevant. For practical purposes, the life cycle of an object is well understood so why complicate things? Perhaps your classmates could also debate whether an object really "exists" once there is no reference to it. Is it in some O-O purgatory waiting for the Garbage Collector to come and finalize it? Does an object have a soul?

[John Smith]

And "instantiated" is also defined to me as having had its constructor executed.
One notable exception is cloning, -- the constructor doesn't need to be invoked when an object is created. Admittedly, this is an extralinguistic facilty in Java, along with reflection.

[Jim Francis]

Originally posted by Gary Mann:
2. IMHO, debates like this can be interesting, but are largely irrelevant. For practical purposes, the life cycle of an object is well understood so why complicate things? Perhaps your classmates could also debate whether an object really "exists" once there is no reference to it. Is it in some O-O purgatory waiting for the Garbage Collector to come and finalize it? Does an object have a soul?

LOL! You think like I do! From the standpoint of the app developer, the loss of the reference should mean the loss of the object. Never hurts to understand what goes on behind the scenes, but that stuff IS irrelevant (almost always) to the OO design. (...of course, with C++ we need to pay a little closer attention, but that's another matter)
This is a test question, that triggered the debate:

The best description of static is:
a.One per instance
b.One per program
c.One per class object
d.One for each instantiation
e.a and d

My contention is that a, c, and d are all same. I believe b is the best answer. Someone (the teacher's boss, mentor, and published Java book author) said the correct asnwer is c. I don't know what he was thinking. Maybe the object of type Class (note that "class" is not capitalized in the question)? Any other way I can interpret c requires instantiation, and we know that instantiation is not required to use the static members of a class.
Thanks for any additional thoughts.

[Jim Francis]

Originally posted by Eugene Kononov:
One notable exception is cloning, -- the constructor doesn't need to be invoked when an object is created. Admittedly, this is an extralinguistic facilty in Java, along with reflection.

Good to know, anyway, even if only to win trivia games. Thanks!