Classworking Toolbox: Generics and ASM

Learn how to use the ASM bytecode framework to access generic information from Java 5

Introduction: JAVA™5 generics provide information that is useful for many classworking. Although Java reflection can be used to get generic information for a loaded class, it is a big drawback that the requirement class must be loaded into the JVM. In this article, classworking spiritual leader Dennis Sosnoski shows how the ASM Java bytecode Manipulation Framework provides flexible access to generic information without the need for Java classloading processing. In this article, he also delves into the generic binary class representation.

Generics information in Java 5 programs is very helpful for understanding the data structure of a program. In the previous issue, I introduced you to the use of run-time reflection to access generic information. This reflection method works very well if you are interested only in obtaining information about the classes that are loaded into the JVM. But sometimes you might want to modify it before loading the class, or you want to study the data structure without loading the class. At this point, reflection is no longer an effective way for you--reflection uses the JVM class structure as an information source, so it works only on classes that have been loaded by the JVM.

To access generic information without loading the class into the JVM, you need a way to read the generic information stored in the binary class representation. In previous installments, we have described how the ASM classworking library provides a clean interface for reading and writing binary classes. In this article, I'll show you how to use ASM to get raw generic information from a class file, and how to interpret generics in a useful way. Before delving into the ASP details, let's take a look at the actual way generics information is encoded into a binary class.

Trace generics

To add typing information that can be used by the Java compiler to the Java binary class, you need to use the generic specification designer. Fortunately, the Java platform already has a mechanism in the binary class format that can be used for this purpose. This mechanism is a property structure (attribute structure), which mainly enables all types of information to be associated with the class itself or the methods, fields, and other components of the class. Some types of property information are defined by the JVM specification, but the original designer of the Java language makes the wise choice to leave a set of possible attributes open, which can be extended by the new version of the specification, or by the user to design their own custom properties.

The generic information is stored in a new standard attribute: the Signature property. This property is a simple text value that decodes generic information for a class, field, method, or variable. The updated Java 5 JVM specification clearly illustrates the complete syntax for signed text values. I do not intend to elaborate here, but the signature is briefly introduced in the section later in this section. You'll start by introducing some of the necessary background information to give you an idea of the internal structure of the class name and the fields and method descriptors used by the JVM.

Deep inside

Classes in the Java platform always come from some packages. When you reference a class name in Java source code, you may or may not actually qualify the package as part of the name. You can always include package qualification (like java.lang.String), but you can also ignore it for the sake of convenience-if the class comes from a Java.lang package or has been import to a source file. This class name structure, which contains a package qualification, is called the fully qualified class name.

Within the actual binary class, the class name is always specified in a package. However, the format of this name differs slightly from the fully qualified class name in the Java source code, replacing the dot (".") with a forward slash ("/"). For example, in the String class, the internal form of the name is java/lang/string. If you try to output or view a class file as text, you will typically see multiple strings in the form above, each of which is a reference to a class.

Class references that take this internal form are used as part of the field and method descriptors. The field descriptor specifies the exact type of a class defined in the class. The notation used depends on whether the field is a simple object type, a simple primitive type, or an array type. The representation of a simple object type begins with an ' L ', followed by an internal form of the object class name, ending with '; '. The notation for primitive types is that each type uses a single letter (such as ' I ' for int, ' Z ' to represent a Boolean type). The representation of an array type is a prefix modifier of ' [' as an array item type, which itself can also be a group type. Table 1 shows an example of each field descriptor and also lists the corresponding Java source code declarations:

Table 1. Field Description Descriptor Example

	source
ljava/lang/string;	string
int
[ljava/lang/object;
boolean["
[[lcom/sosnoski/generics/fileinfo;	com.sosnoski.generics.fileinfo []

The method descriptor combines a field descriptor to specify the parameter type and return type of the method. The format of the method descriptor is very easy to understand. Starts with a field descriptor for the following parameter (all run together), followed by ') ', ending with the return type (if the return type is void, ending with ' V '). Table 2 shows some examples of method descriptors, along with the corresponding Java source code declarations (Note that the method name and the parameter name itself are not part of the method descriptor, so a placeholder is used in the table):