Where are the Class objects created by classloader subsytem stored?

Question

I guess the newer versions of java have combined both method area and heap area as only one heap area. But this is regarding older versions.

But the jvm loading definition states as the "process of finding a .class file and creating a Class object"

These are my doubts:

1. When we run our .class file, is it first stored as memory bits as-is in method area? Is the complete .class file just converted to memory bits? Or just the metadata? What exactly is the pattern of memory allocation of this "class data" in method area?
2. Does a Classloader class use methods of Class class to obtain this metadata which is eventually stored in method area?
3. Are these Class objects same as objects we create using new? I already looked at the documentation but still cant figure out during which step a Class object is created. Is the .class file information converted to metadata and saved as Class objects on method area?

I already looked at the documentation. I only need a simple explaination of what is "loaded"? Method area has Class objects that have this metadata ? Or just bit-by-bit info of the entire .class file ?

Edit: Also I know that by "writing/running a code" itself means this entire file is in bit format on RAM. I want to know if this special method area on RAM just has this copy or its completely different.

Answer 1

For a full explanation of how this works, you need to read chapter 5 of the Java Virtual Machine Specification. The introduction states,

" The Java Virtual Machine dynamically loads, links and initializes classes and interfaces. Loading is the process of finding the binary representation of a class or interface type with a particular name and creating a class or interface from that binary representation. Linking is the process of taking a class or interface and combining it into the run-time state of the Java Virtual Machine so that it can be executed. Initialization of a class or interface consists of executing the class or interface initialization method "

To answer the specific questions:

1. The classfile is not loaded as-is into the method area, it is loaded as an implementation specific (meaning the JVMS doesn't mandate it) internal representation of the class. Classes (other than array classes) are loaded by a class loader. The class loader creates an instance of the Class object (ie the meta-data) for the given class. Allocation of space in the heap for this object is handled by the JVM.
2. No. The class loader is responsible for creating the Class object so does not use methods of that object.
3. Yes, Class objects are the same form as any other Java object. The Class class inherits from Object and you can call methods such as equals, hachCode, etc. just as you would on other objects.

Answer 2

A ClassLoader is only responsible for locating and reading the class file and optionally, associate a ProtectionDomain with the code location, to support security measures.

It then passes the bytes to one of the defineClass methods, every class loader inherits. These methods take the class file bytes, either as array or ByteBuffer , and do the entire magic, finally returning a Class object.

These Class objects are mostly like ordinary objects, but you never create them via new ; only the JVM will create instances. Further, the JVM may associate additional information with these objects, not visible to the application programmer looking at the Java object.

What happens within defineClass , is implementation specific. But it is typical, not to store the class file bytes as-is. They likely contain information not needed for execution and required information may not be in the optimal format for the current platform (like byte order and preferred data alignment). Further, it makes sense to fold identical constants of different classes into one storage. Since the class data have to be checked for validity anyway, it makes sense to combine that processing step with converting the data into an internal format better suited for subsequent processing.

The complete runtime information regarding a class still are distributed over the heap (like the Class instance and its associated Reflection objects) and the Method Area (like code, linkage information, JVM internal structures, etc.). Note that these names are given by the specification, ie the Java Heap is defined as the memory area containing all Java objects and the Method Area is defined as the storage of the meta data . Since this distinction is given by definition , regardless of whether it makes a difference to the particular implementation (after all, it's just RAM), you won't see an implementation dependent change in this classification.