This chapter of JVM Specification describes three phases of life of a JVM class: loading, linking and initializing.

In order to start executing main method (public void main(String[] args)) of the main (or: initial) class the JVM needs to have a runtime representation of the class. If JVM does not have it, it needs to construct it from binary representation. This is called loading.

The weather is still “very february”, so I grab a cup coffee ☕, start reading and taking notes.

This post completes Chapter 4 of the JVM Specification - it quickly goes through format checking, shows two types of Code attribute checks and lists JVM limitations.

Format Checking

Before the class is loaded, JVM needs to ensure that the .class file has appropriate format. There are five basic integrity checks that are performed on a .class file:

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:

It’s snowy, windy and dark outside. It is a perfect weather to read a technical spec, isn’t it?

Let’s read about a .classfile’s constant pool today.

This post is a note taken during reading 4.2 and 4.3 sections of chapter 4.

Section 4.2 describes the rules of representing class and interface names, field and method names, module and package names.

Section 4.3 describes descriptors and provides a short grammar according to which a representation of a type is constructed.

Names

Binary class and interface names

• those names always appear in a fully qualified form known as binary name (see JLS 13.1)
• they are represented with forward slash instead of a dot (for historical reasons)
• represented as CONSTANT_Utf8_info structures
• referenced from CONSTANT_NameAndType_info and from CONSTANT_Class_info structures

Field and method names

Unqualified names are used to strore:

Class File

Each .class file contains the definition of a single:

• class
• interface or
• a module

Class format (the specific order and meaning of bytes) described in the spec not neceserily applies to an actual file on the filesystem: those “bytes” might have been read from the database, downloaded from the web or constructed by a class loader; keep this in mind whenever you encounter the phrase “class file format”.

Here’s a short overview of the instruction set for the JVM.

Chapter 2 reading notes: types and runtime data areas, and a bit about threads. Opcodes will come soon 😄! Source: chapter 2 of JVM specification.

Let’s start small: start by reading the specification’s introduction