This chapter is from the book
This chapter is from the book
This chapter is from the book
3.7 Custom Metadata
The type information stored in a Java class file is very thorough, as far as it goes. When you first move to Java from a nonreflective programming environment, the new possibilities seem limitless. Knowing the names and types of all methods and fields makes it easy to implement all sorts of runtime services for your Java objects: XML views, object/relational mappings, generic user interfaces, and on and on. Nevertheless, it is possible to imagine wanting even more metadata.
Consider the hypothetical LaunchVehicle interface shown in Listing 3–27. As a human reader, you can infer several important details about how to use this interface. For example, you know to use liters when you addFuel. From your knowledge of the problem domain, you know that you should always countdown before you launch. These are important, contractual elements of the interface, but they do not have a standard language representation and are not part of the class metadata. You cannot count on clients always getting these details correct. Even if you could, some other important details of the design are not obvious to the reader. What units are to be used when calling thrust? Is it acceptable to addFuel during the countdown? This example illustrates the need for two kinds of metadata not available to the Java language: the correct units for numeric arguments, and tables of state transitions allowed by an interface. If these metadata elements were added to Java, the virtual machine could enforce the rules for you, eliminating two more sources of program errors.
Listing 3–27 The LaunchVehicle Interface
public interface LaunchVehicle {
public void addFuel(int liters);
public void countdown(int seconds);
public void launch(int thrust);
//etc.
}
It would be unreasonable to expect a Java virtual machine to support every possible flavor of useful class metadata. Virtual machines would need to be far more complex than they are today, and classes would carry around enormous amounts of metadata not useful to their problem domain. It was good design to limit the scope of the virtual machine's responsibilities; the line had to be drawn somewhere.
Fortunately, the virtual machine specification offers a hook for customization by permitting the addition of custom attributes to the class file format. Attributes can be any binary data, and they are housed in a data structure called an attribute_info. The attribute_info structure, shown in Listing 3–28, contains a constant pool index to a string that names the attribute, plus an opaque array of bytes containing the attribute's data. You can attach attributes to classes, methods, fields, or even to the bytecodes that implement a method.
Listing 3–28 The attribute_info Structure
//pseudocode from the JVM spec
attribute_info {
u2 attribute_name_index; //reference to constant pool
u4 attribute_length;
u1 info[attribute_length]; //custom data
}
Figure 3–6 is an expanded view of the binary class format diagram, originally presented in Figure 3–1, with custom attributes shown below the solid line. The virtual machine spec already defines some standard attributes for its own use. The bytecodes that implement a method are stored as an attribute, which can in turn have custom subattributes. The standard attributes defined by the specification are listed in Table 3–3.
){kind=link}
){kind=link}
Figure 3–6 Custom metadata in the binary class format
Table 3–3 Attributes Defined by the Virtual Machine Specification
|
Attribute Name |
Attibute Purpose |
|
Code |
Holds bytecodes that implement a method |
|
ConstantValue |
Holds value used to initialize a constant field |
|
Exceptions |
Lists checked exceptions a method may throw |
|
InnerClasses |
Links nested classes and outer classes |
|
Synthetic |
Marks methods not present in original source file |
|
SourceFile |
Holds name of original source file |
|
LineNumberTable |
Maps bytecode offsets to source line numbers |
|
LocalVariableTable |
Maps variables to source variable names |
|
Deprecated |
Marks deprecated class, field, or method |
The Code, ConstantValue, and Exceptions attributes contribute to the documented semantics of class files and must be understood by conformant virtual machine implementations. The InnerClass and Synthetic attributes contribute to the semantics of the core API libraries and will therefore also be understood by compliant virtual machines.
The remaining standard attributes provide useful information, but they are not essential for the correct functioning of the language. For example, the SourceFile, LineNumberTable, and LocalVariableTable attributes enable source-level debuggers. Because these attributes are optional, they can be silently ignored by virtual machines that do not understand them. Any custom attributes that you develop must also be optional.
If a custom attribute were necessary for a class to function correctly, then a standard virtual machine would be unable to load a class that relied on the custom attribute. Such a custom attribute would encourage developers to write nonportable Java classes, defeating the write-once, run-anywhere nature of the language. It is legal to write custom tools that manipulate or even mandate custom attributes, but virtual machine implementations must silently ignore attributes that they do not recognize. The rules limit custom attributes to optional data that adds value when it is recognized by the virtual machine but does not break functionality when it is not. Even when they are operating within this constraint, custom attributes have many uses. They can store domain-specific metadata, debugging information, profiling information, documentation, and JIT optimization hints or hints that support interoperation with other programming environments.
Standard Java compilers will not emit your custom attributes, and the Reflection API provides no support for accessing them. If you want to define and use custom attributes, you will need to develop a development tool that injects attributes, a custom class loader that tracks attributes as classes are loaded, and extensions to reflection that can access these attributes at runtime.
Custom attributes are not in wide use today because they receive only limited support from the standard Java tools. Java compilers typically do not emit custom attributes, which is not surprising since there is no Java syntax for defining them. Programmers who want to add custom attributes must write their own tools to crack the class file format and inject attributes. Such tools are easy to write, and many are freely available, but none have the blessing of being standardized.
You are also on your own for extracting custom attributes. The Reflection API currently does not define methods for extracting custom attributes, although such methods are easy to design and add. Listing 3–29 shows part of the Java Class File Editor (JCFE). JCFE is an open source library developed by the author for manipulating custom attributes; see [JCFE] for details. The ClassEx augments the standard java.lang.Class class to include access to custom attributes, and the Attribute base class (not shown here) can be used as a subclass for different custom attributes that you design.
Listing 3–29 JCFE Methods for Custom Attributes
package com.develop.reflect;
public class ClassEx {
public void addAttribute(Attribute ca);
public Attribute[] getAttributes(String name);
public Attribute[] getAttributes();
}
In order to access custom attributes at runtime, you need a custom class loader to extract them. A class loader sees the class file as a byte array during findClass, which provides a hook for manually parsing the class file and remembering any custom metadata. §5.5 develops a full example of this technique, using custom attributes and a custom class loader to automatically locate the correct version of a Java class.
Because the virtual machine must already parse the binary class format, parsing the class file a second time in a custom loader is inefficient. In an ideal world, access to custom attributes belongs in the platform, not in custom loaders. Hopefully a future version of Java will move custom attribute support into the core API.