To add to that... it looks like the 5 things listed on p. 7 correspond
to different parts of the ClassFile structure, except I'm not clear
what happens to the other parts of the class file that are not listed
as one of the 5 things... for example, does the minor and major version
get stored in the class area?  How about all of the class attributes --
do they go into the class area too?  The access flags?  The
"this_class" ref?  The magic number?

Thanks,
- Will

I think it's probably worth taking a step back and looking at this from a
slightly wider perspective.  I can't remember much detail about Engel's book,
but I don't remember that the "class area" concept really helps with anything
at all.

It may be worth emphasising that the .class file format has nothing to do with
the internal operation of a JVM implementation.  That format is an
implementation-independent /transfer/ format, and there is little chance of it
being very useful for anything else.  So the JVM will /parse/ that format, and
build up its own internal data structures containing equivalent data in
whatever format(s) and arrangements best suit its own implementation.

To give some examples:

The integer bitsets used to mark members as public/private/default/protected,
are inconvenient to use since "default access" has value 0 -- which makes code
that tests access permissions more complicated than it should be.

At the other end of the scale, the bytecodes themselves are overcomplicated and
underefficient.  A JVM that uses an interpreter might choose to rewrite them
into a more efficient internal format (maybe 16-bit).  It's possible that a
JITing JVM might translate them into a format that the JITer found easier to
handle, though I don't know whether that would actually be worth the extra
effort.  In any case, a JITing JVM would -- by definition -- translate (some
of) the bytecodes into machine-native form, and the resulting buffers of
machine-code would have to be stored, and linked to from the class/method
definitions.

As a last example, the "constants pool" in a class file is /only/ there as a
way of reducing the size of the classfile.  Its a compression technique,
nothing more.  There is no reason on God's earth why a JVM implementation would
want to keep it hanging around. (Which is another reason why the .classfile
bytecode format -- which refers to the constants pool -- is unsuitable for
direct interpretation.)

So the JVM will /extract/ the information that it wants from the classfile.
That will almost certainly end up being represented as things like hashtables,
lists, and arrays of whatever internal structures the JVM uses to represent
classes and methods.  (The instances of java.lang.Class would contain
internal -- hidden -- references to that data.)  That large and complicated
(set of) data structures is what Engle's (and the JVM spec too, IIRC) lump
together and call the "class area".  It has no real existence as anything
except an expository short-cut.

The bottom line is that the class area "contains" /everything/ that the JVM
needs to remember about classes in order to run.

   -- chris

can u please let me know the title of the book you are reading. I am,
too, interested in reading about jvm. Thanks

-Regards
Madhur

Personally, I find the O'Reillys 'Java Virtual Machine' much clearer to
read on JVM concepts when compared to Engel's book. Engel's book
contribution is from chapter 10 onwards - how to implement different
languages when targeting to the JVM.

What about reading some pages more ;)

 [lots of speculation deleted. what about using paragraphs in
  postings?]

He referring to JVM runtime view. Class area is the runtime storage of
classes, whatever its internal representation might be. Pages 8-20 give
elaboration on these concepts.

Code is not a JVM attribute, but a method's attribute. Information on
class properties conceptually belongs to class area, as it is not
runtime stack information, heap information, or native method stacks.

For clarity on JVM definition, I really recommend the O'reillys book
over Venners' and Engel's. When writing my Java interpreter, I found the
O'reilly's one to be most accessible.

br,
Pietu Pohjalainen