JVM: Fields, Methods, Attributes

Attributes in the .class file layout

In previous post I made some notes about constant_pool. Looking at the order in which data is layed out in the class file, constant_pool is followed by some general information specific to the class like its name, names of implemented interfaces or its superclass (see the post JVM: Class file structure). Information about fields and methods comes next.

Both fields as well as methods are represented with the same general structure:

method_info {
  u2 access_flags;
  u2 name_index;
  u2 descriptor_index;
  u2 attributes_count;
  attribute_info attributes[attributes_count];


field_info {
  u2 access_flags;
  u2 name_index;
  u2 descriptor_index;
  u2 attributes_count;
  attribute_info attributes[attributes_count];

The fields come first in the .class file, then the methods. Fields and methods info:

  • have separate list of valid access flags
  • their descriptor_index points to constant_pool with appropriate descriptor (see JVM: Names and Descriptors)
  • differ with attributes that are allowed in corresponding attributes arrays (for a list of locations where an attribute may appear - class, field or method - see Attributes table in JVM Specification

Differece between allowed flags in fields (left) and methods (right): Difference between field and method access flags

Finally, the last section of the .class file consists of a table of top-level, class-related attributes.

In next section I will check where the attributes may appear in the .class file structure and what is the structure of the attribute itself.

Location and structure of an attribute

In general, there exist four locations where attribute_info may appear in the .class file:

  • field_info (see above)
  • method_info (see above)
  • ClassFile - top level attributes table
  • Code_attribute - this attribute may appear only inside attributes table of method_info structure
  • record_component_info - this attribute may appear only in attributes table of ClassFile structure

It’s interesting that there is so many semantic information about the class and its content that they form a nested structures of attributes:

  • Top level attributes table may contain info about record components in Record_info (if the .classfile defines a record class) and each of them has a components table with record_component_info structures, each having attributes table with attribute_info structures.
  • Similarly, method_info structure describing a method may have Code_attribute attribute which in turn has nested attributes.

So, what is the shape or the structure of an attribute?

The structure of an attribute

attribute_info {
    u2 attribute_name_index;
    u4 attribute_length;
    u1 info[attribute_length];

Here we have

  • index into constant_pool with name
  • length in bytes of the info table
  • and the data itself of given length

Attribute groups

There are 30 predefined attributes split into three groups:

  • 7 critical to correct interpretation of class file by JVM
  • 10 not critical to JVM but critical to interpretation by JavaSE libraries or tools
  • 13 exposed by JavaSE libraries or containing metadata that are made available by tools
Critical Not critical Exposed
ConstantValue Exceptions SourceDebugExtension
Code InnerClasses Deprecated
StackMapTable EnclosingMethod RuntimeVisibleAnnotations
BootstrapMethods Synthetic RuntimeInvisibleAnnotations
NestHost Signature RuntimeVisibleParameterAnnotations
NestMembers Record RuntimeInvisibleParameterAnnotations
PermittedSubclasses SourceFile RuntimeVisibleTypeAnnotations
LineNumberTable RuntimeInvisibleTypeAnnotations
LocalVariableTable AnnotationDefault
LocalVariableTypeTable MethodParameters

Class file may also contain other attributes than those predefined. These should not change the semantics of existing, predefined attributes and should also be quietly ignored by jvm or tools that encounter them.


88 pages of attribute descriptions follow. What are those most interesting? Well, probably those that were categorized as critical, so let’s have a look.


Represents the value of a constant expression (a field). It will be ignored in case the field has no ACC_STATIC flag in access_flags items of field_info structure.

In other words: keeps the index into the constant_pool where the constant value is stored during initialization of the class/interface where the final field is defined.

Code attribute

This is attribute of a method and appears in method_info structure. It has interesting contents:

  • maximum depth of operand stack at any point of execution
  • number of local variables in local variable array allocated as part of a frame after this method is called (both local variables defined in a method and parameters passed to the method at the call site)
  • code array of bytes with actual bytecodes
  • exception table with entries containing:
    • start and end - the range inside code array protected by exception handler
    • index in code where handling code starts
    • catch_type - index into constant_pool with CONSTANT_Class_info of the exception class (or value 0 if it is “catch all” case)
    • …and count followed by a attributes table with count attributes

(Here I had my a-ha moment when I realized that this is the information that I see in “Code:” section when I execute javap -v some_class.class)


Contains data used during verification by type checking.

  • it describes some code offsets - usually containing jump instructions (i.e. invokeXXX)
  • and for those offsets it says what are the types of values that should be available at the stack and in local variable array at the moment of the call
  • it also checks the shape of the frame, i.e. if the number of locals is not greater than the max number of locals defined in the method


This attribute stores a count and a table of references to CONSTANT_MethodHandle_info structures in constant pool together with an array of arguments of the method (also defined as count and tablel of indices into constant_pool).

The method handle will e resolved during resolution of dymamic constant or call site and then invoked with given arguments.

NestHost and NestMembers attributes

(Here comes the magic of how it is possible that nested classess can access private members of containing class.)

A nest is a set of classes and interfaces that allow mutual acces to their private members. One of them is nest host and in its NestMembers attribute it enumerates all classes that belong to its nest. Those other classes designate (in their NestHost attribute) this class as their “host”.

PermittedSubclasses attribute

This attribute enumerates what classes or interfaces are allowed (or: are authorized) to extend (implement) this class (interface).

The presence of this attribute is the result of using sealed class modifier in java source file. There is no ACC_SEALED access flag.


I went through the structure and types of attributes. I’ve seen where those attributes are located in the layout of the class file. I shortly described some of them (the 7 “critical” ones).

Now it’s time to go through all others as well. So I will prepare a hot, tasty tea (or, let’s say, a cup of yerba) and will dig deeper. Even if some of them seem a bit mysterious, I shall not surrender!

(Yup, it’s boring. That’s why I even started thinking about writing a side project that would help me track my progress when reading the spec 😂, but then I realized that this approach would mean I won’t be able to make any progress for a while, so I dropped the idea altogether.)

Have a nice evening!

Ten wpis jest częścią serii jvm.

Wszystkie wpisy w tej serii: