<<  Page 2 of 6  >>

Advertisement

Loading

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

• given the type's fully qualified name, produce a stream of binary data that represents the type
• parse the stream of binary data into internal data structures in the method area
• create an instance of class java.lang.Class that represents the type

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:

• load a Java class file from the local file system
• download a Java class file across a network
• extract a Java class file from a ZIP, JAR, CAB, or other archive file
• extract a Java class file from a proprietary database
• compile a Java source file on the fly into the class file format
• compute the class file data for a type on the fly
• any of the above, but using a binary file format other than the Java class file

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  >>

Table of Contents | Order the Book | Email | First Page | Previous | Next