I can understand the frustration that comes with trying to learn the language and being denied a visual in a situation like this. Unfortunately, Mr. F-H is right...for all intents and purposes, it simply doesn't matter where a particular JVM keeps this information as long as it's available when it's needed.
From a visualization standpoint, that's not a satisfying answer. So, let me give this question a shot. Beware, though,
what I'm about to tell you is not actually true--it's just a good way to think about it.
As you already know, each instance of a class--each object--is dynamically allocated on the heap. So, if you think about it, what varies from one instance to the next? The instance data does...what about the methods? These vary only in the sense that they operate on a different instance's data...other than that, these do not vary from instance to instance. If I have two instancese of the Dog class, fido and rover, the eat() method executes the same sequence of steps for both fido and rover, but calling fido.eat() only alters fido's state (makes him full)...it has no effect on the data in memory associated with rover.
If I write a class Foo that has a method bar(int x), that method bar() takes an int and executes the same sequence of steps regardless of which instance owns it. I'm sure you've read about the this reference...that's how one copy of bar() in memory actually knows which instance it's working on. Every instance method implicitly passed a this reference which points to the relevant instance.
Static methods are not specific to a particular instance, so those do not get passed a this reference behind the scenes like instance methods do. That's why you can't call an instance method from a static method without referencing a specific object instance. Example:
So clearly, since each instance method has this implicit this reference passed to it, it would be a waste of memory for each instance to maintain a separate copy of its methods. If I had 100 instances of the Foo class instantiated, it makes sense that we should only need a single copy of these methods...we only need to keep 100 separate sets of data maintained by each Foo instance and pass around the appropriate this reference.
So the methods (both instance and class methods) only need one copy floating around of that executable code. Also, as you know, we only need one copy for static data as well. Where to put it?
Imagine if we had a class that represents classes. An instance of that class could represent the Foo class. Another instance might represent the Xyzzy class. The instances of this "class class" could serve as an object for containing all of the class' methods and static data. Fortunately, we have such a class...it's called the java.lang.Class class.
So (and again, this isn't an accurate representation of what's actually going on, it's just a good visualization device), you can think of each class existing itself in memory as an object, a Class instance. These objects exist like any other objects, and contain the common stuff for that particular class as instance data within itself.
I'll leave you to visualize how this works for the Class class itself.
sev
[ August 02, 2004: Message edited by: sever oon ]
. It will look at it the way the implementors tell it to. 
