Classes, Class Files and Class Loading

An application program written in Java language is first compiled into the Java bytecode. During compilation all the methods used in the program are compiled separately, and stored in class files. This does not include the methods imported from the standard library. They are just referenced, and the virtual machine links them in during the execution. A single class can contain, and they usually do, several methods. The class files contain also other data, most importantly the constant pool. The constant pool is used for storing constant values and strings as well as for storing method names. During the initialization a virtual machine first sets some internal prop- erties, usually related to the underlying operating system, current time and so on. After this the virtual machine loads the starting method, usually the main(), of the user application.

The Class File Format

The classes that make up an application are delivered in the class file for- mat, described in the Java Virtual Machine Specification [38] and shown in Figure 2.4. The class files are similar to object files generated by normal compilers (for example GCC). A class file contains several critical pieces of

6

data, such as the bytecode segments that make up the methods in the class, a reference to the superclass of this class, a list of the fields defined by the class, the constant pool of this class and other data required by the virtual machine.

All valid class files start with a magic number 0xCAFEBABE. This is followed by version information of the class. Then the tables containing the constant pool, methods and other data items are defined. The last table is for the attributes of the class, and it can contain arbitrary definitions. If the virtual machine running the application does not understand some of the defined attributes, they are simply ignored.

The constant pool of a class is used to store a mixture of data items. These include names of the methods and the fields, the numerical constant values and the string constants belonging to the class. The method invoca- tions in Java use the class and method names stored in the constant pool to find the required method. Since the constant pool is used frequently, it is important that the virtual machine can access it efficiently.

The class files are often packaged into “Java archives” (JAR). As a de- ployment form, the JAR file format provides many benefits over distributing the class files separately. Most notable benefits include:

• Security: The contents of a JAR file can be digitally signed. If a virtual machine recognizes the signature, it can then optionally grant the application security privileges it would not otherwise have. • Compression: The JAR format allows the compression of the class

files for efficient storage.

• Decreased download time: If an application is bundled in a JAR file, the class files and associated resources can be downloaded in a single transaction without the need for opening a new connection for each file. Naturally, the compression also reduces the download time. • Package sealing: Packages stored in JAR files can be optionally sealed so that the package can enforce version consistency. Sealing a package within a JAR file means that all classes defined in that package must be found in the same JAR file.

• Package versioning: A JAR file can hold data about the files it contains, such as vendor and version information.

0xCA 0xFE 0xBA 0xBE

Fields

Class file version

Constant pool

Super class

This class

Intefaces

Methods

Attributes

Access flags

Figure 2.4: The structure of a Java class file.

Besides the actual class files, the JAR file contains metadata defining the main method of the application. The JAR file may also contain other pieces of data, such as an icon for the application, audio and images. The support for the zip packing is optional in the specification, but most virtual machine implementations include it.

Class Loading (and Unloading)

When a virtual machine starts to execute an application it first loads the main class of the application. Loading is the process of retrieving the data that defines a class. Classes can be loaded from any source, including (but not limited to) ROMs, disks and network connections. All further classes are loaded when they are needed.

The specification defines two mechanisms for class loading. The more important one is system class loader, which is a built-in class loader used for the standard classes in the classpath and also for the classes of the user application. The other mechanism uses a user defined instance of the ClassLoader. The latter is sometimes disabled for security reasons, since it would enable malevolent programmers to load and execute arbitrary Java code via web browsers etc.

After a class has been loaded it is not ready to be executed. It requires further processing steps. The next step is linking, which may cause new classes to be loaded recursively in order to find all the necessary super- classes. This step also performs verification of the previously loaded class. Some virtual machines omit the verification completely while others verify only some of the classes. A virtual machine may well believe that its own standard classes are safe and thus they are not necessarily verified.

After the verification the class is prepared. During preparation the static fields are given their initial values. This is followed by initialization, when the virtual machine first checks that all of the required superclasses have been initialized. Then the static initialization methods defined in the class are invoked. At this point the methods contained in the class are ready to be used.

The specification allows also the removal of previously loaded classes. This is done if the virtual machine wants to perform garbage collection on the loaded classes. The functionality is not defined in the specification, but if a finalizer method exists in the class, then it will be invoked before unload- ing of the class. This functionality is not present in all of the Java virtual machine implementations.