The Artima Developer Community
Sponsored Link

Chapter 7 of Inside the Java Virtual Machine
The Lifetime of a Type
by Bill Venners

<<  Page 2 of 6  >>



The loading process consists of three basic activities. To load a type, the Java virtual machine must:

The stream of binary data may adhere to the Java class file format, but could alternatively follow some other format. As mentioned in previous chapters, all Java virtual machine implementations must recognize the Java class file format, but individual implementations may also recognize other binary formats.

The Java virtual machine specification does not say how the binary data for a type must be produced. Some potential ways to produce binary data for a type are:

Given the binary data for a type, the Java virtual machine must process that data to a great enough extent that it can create an instance of class java.lang.Class. The virtual machine must parse the binary data into implementation-dependent internal data structures. (See Chapter 5, "The Java Virtual Machine," for a discussion of potential internal data structures for storing class data.) The Class instance, the end product of the loading step, serves as an interface between the program and the internal data structures. To access information about a type that is stored in the internal data structures, the program invokes methods on the Class instance for that type. Together, the processes of parsing the binary data for a type into internal data structures in the method area and instantiating a Class object on heap are called creating the type.

As described in previous chapters, types are loaded either through the bootstrap class loader or through user-defined class loaders. The bootstrap class loader, a part of the virtual machine implementation, loads types (including the classes and interfaces of the Java API) in an implementation-dependent way. User- defined class loaders, instances of subclasses of java.lang.ClassLoader, load classes in custom ways. The inner workings of user-defined class loaders are described in more detail later in Chapter 8, "The Linking Model."

Class loaders (bootstrap or user-defined) need not wait until a type's first active use before they load the type. Class loaders are allowed to cache binary representations of types, load types early in anticipation of eventual use, or load types together in related groups. If a class loader encounters a problem during early loading, however, it must report that problem (by throwing a subclass of LinkageError) only upon the type's first active use. In other words, if a class loader encounters a missing or malformed class file during early loading, it must wait to report that error until the class's first active use by the program. If the class is never actively used by the program, the class loader will never report the error.

<<  Page 2 of 6  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use