Classworking Toolbox: Analyzing generic data structures

Apply type substitution drill down to dig into the details of a program that uses generics

Introduction: The Java™5 generics encode detailed type information into the class file. Many types of tools can benefit from an improved data structure provided by a comprehensive type of information, but it can be difficult to make this information a useful form. To make this work easier, the series author Dennis Sosnoski built a data structure analyzer around the ASM Java bytecode manipulation framework to interpret generic information and create a view of the depth for the actual data type of the data used by the application.

A class-processing tool is actually a program that treats other programs as data, often modifying or reshaping the target program to meet certain purposes. When you use a program as data, it is often useful to build a model of the internal data structure of the program itself to help guide the changes. You can use reflection to create this type of model after the first time the class files of the target program have been loaded into the JVM. can also use the framework directly from the class file decoding data structure information, or even from the source code to decode. Regardless of the technique used, the goal is to get the broadest possible view of the relationships between objects used by the application.

The generics information in the Java 5 program provides a detailed map of the application data structure. Before generics, the analysis of data structures goes into a dead end as long as you run to a Java collection class or use an application class that has no type reference. Without some form of external information, there is no way to know what type of object an untyped reference is linked to. When using generics, you can provide additional information as part of the source code, and the compiler will then integrate the additional reference type information directly into the binary class file. Leveraging this embedded generic information is key to building a richer view of the relationships between objects.

In the first two articles of the series (reflection generics and generics and ASM), I started with the basics of using reflection to get generic information, and then introduced the raw generic information for processing class files using the ASM bytecode framework. In this article, I've used the ASM technology a little bit more, using type substitution in generic class definitions to build an enhanced view of the target application's data structure. Before entering the actual ASM code used in the analysis class, let me first introduce some simple questions about representing and organizing data structure information.

Represents a data structure

The first problem when building an analyzer is to define the representation of the data structures used by the target program. This must include not only the representation of each field value, but also the type information representation of each value. Because I want to demonstrate the decoding of generics in this period, the type information needs to contain the specific parameter types used by the generic reference.

Listing 1 shows the classes I represent as basic data structures. The Fielddescription class is just a simple data class that holds references to field names, signatures, and field types. As I described in the previous issue, signatures are items that generics add to the class file format, and only references to generics are signed. The signature defines the type of parameter that the generic is actually using, so it provides the information needed to handle the type substitution. For fields that do not have a signature, only null values are used. Finally, the field type is an instance of the Typedescription class, as shown in Listing 1:

Listing 1. Basic Data structure Classes

public class Fielddescription
{
Every field has a name
Private final String M_name;

Only fields that are of generic types have signatures
Private final String m_signature;

Type only defined when parameter types are defined
Private final typedescription M_type;

Public fielddescription (string name, string sig, Typedescription type) {
M_name = name;
M_signature = sig;
M_type = type;
}

Public String GetName () {
return m_name;
}
Public String getsignature () {
return m_signature;
}
Public Typedescription GetType () {
return m_type;
}
}

Public abstract class Typedescription
{
public static final fielddescription[] Empty_field_array = {};

Private final String M_descriptor;

Protected typedescription (String dtor) {
M_descriptor = Dtor;
}

public Boolean IsArray () {
return false;
}
Public Typedescription Getarrayitemtype () {
throw new IllegalStateException ("not a array");
}
public Boolean isprimitive () {
return false;
}
Public fielddescription[] GetFields () {
return empty_field_array;
}
Public String GetDescriptor () {
return m_descriptor;
}

public boolean equals (Object obj) {
if (obj = = this) {
return true;
else if (obj instanceof typedescription) {
Return M_descriptor.equals ((typedescription) obj). M_descriptor);
} else {
return false;
}
}

public int hashcode () {
return M_descriptor.hashcode ();
}

Public abstract String toString ();
}

The Typedescription class is simply an abstract base class that defines methods for handling three types: native types, arrays, and class instances. This base class contains a value in the form of a type descriptor. The type descriptor I use for this class is roughly in the form of the type descriptor defined by the JVM specification, but some extensions have added the actual argument type list for the generic specific version. This extension allows the ljava/util/map<ljava/lang/string; ljava/lang/string;>; This form of descriptor is used as part of the type system.