Getting Started with Javassist
Previous page

5. Bytecode level API

6. Generics

7. Varargs

8. J2ME

9. Boxing/Unboxing

10. Debug

5. Bytecode level API

Javassist also provides lower-level API for directly editing a class file. To use this level of API, you need detailed knowledge of the Java bytecode and the class file format while this level of API allows you any kind of modification of class files.

If you want to just produce a simple class file, javassist.bytecode.ClassFileWriter might provide the best API for you. It is much faster than javassist.bytecode.ClassFile although its API is minimum.

5.1 Obtaining a ClassFile object

A javassist.bytecode.ClassFile object represents a class file. To obtian this object, getClassFile() in CtClass should be called.

Otherwise, you can construct a javassist.bytecode.ClassFile directly from a class file. For example,

This code snippet creats a ClassFile object from Point.class.

A ClassFile object can be written back to a class file. write() in ClassFile writes the contents of the class file to a given DataOutputStream.

You can create a new class file from scratch. For example,

ClassFile cf = new ClassFile(false, "test.Foo", null);
cf.setInterfaces(new String[] { "java.lang.Cloneable" });
FieldInfo f = new FieldInfo(cf.getConstPool(), "width", "I");

cf.write(new DataOutputStream(new FileOutputStream("Foo.class")));

this code generates a class file Foo.class that contains the implementation of the following class:

package test;
class Foo implements Cloneable {
    public int width;

5.2 Adding and removing a member

ClassFile provides addField() and addMethod() for adding a field or a method (note that a constructor is regarded as a method at the bytecode level). It also provides addAttribute() for adding an attribute to the class file.

Note that FieldInfo, MethodInfo, and AttributeInfo objects include a link to a ConstPool (constant pool table) object. The ConstPool object must be common to the ClassFile object and a FieldInfo (or MethodInfo etc.) object that is added to that ClassFile object. In other words, a FieldInfo (or MethodInfo etc.) object must not be shared among different ClassFile objects.

To remove a field or a method from a ClassFile object, you must first obtain a java.util.List object containing all the fields of the class. getFields() and getMethods() return the lists. A field or a method can be removed by calling remove() on the List object. An attribute can be removed in a similar way. Call getAttributes() in FieldInfo or MethodInfo to obtain the list of attributes, and remove one from the list.

5.3 Traversing a method body

To examine every bytecode instruction in a method body, CodeIterator is useful. To otbain this object, do as follows:

A CodeIterator object allows you to visit every bytecode instruction one by one from the beginning to the end. The following methods are part of the methods declared in CodeIterator:

The following code snippet displays all the instructions included in a method body:

5.4 Producing a bytecode sequence

A Bytecode object represents a sequence of bytecode instructions. It is a growable array of bytecode. Here is a sample code snippet:

This produces the code attribute representing the following sequence:

You can also obtain a byte array containing this sequence by calling get() in Bytecode. The obtained array can be inserted in another code attribute.

While Bytecode provides a number of methods for adding a specific instruction to the sequence, it provides addOpcode() for adding an 8bit opcode and addIndex() for adding an index. The 8bit value of each opcode is defined in the Opcode interface.

addOpcode() and other methods for adding a specific instruction are automatically maintain the maximum stack depth unless the control flow does not include a branch. This value can be obtained by calling getMaxStack() on the Bytecode object. It is also reflected on the CodeAttribute object constructed from the Bytecode object. To recompute the maximum stack depth of a method body, call computeMaxStack() in CodeAttribute.

Bytecode can be used to construct a method. For example,

ClassFile cf = ...
Bytecode code = new Bytecode(cf.getConstPool());
code.addInvokespecial("java/lang/Object", MethodInfo.nameInit, "()V");

MethodInfo minfo = new MethodInfo(cf.getConstPool(), MethodInfo.nameInit, "()V");

this code makes the default constructor and adds it to the class specified by cf. The Bytecode object is first converted into a CodeAttribute object and then added to the method specified by minfo. The method is finally added to a class file cf.

5.5 Annotations (Meta tags)

Annotations are stored in a class file as runtime invisible (or visible) annotations attribute. These attributes can be obtained from ClassFile, MethodInfo, or FieldInfo objects. Call getAttribute(AnnotationsAttribute.invisibleTag) on those objects. For more details, see the javadoc manual of javassist.bytecode.AnnotationsAttribute class and the javassist.bytecode.annotation package.

Javassist also let you access annotations by the higher-level API. If you want to access annotations through CtClass, call getAnnotations() in CtClass or CtBehavior.

6. Generics

The lower-level API of Javassist fully supports generics introduced by Java 5. On the other hand, the higher-level API such as CtClass does not directly support generics. However, this is not a serious problem for bytecode transformation.

The generics of Java is implemented by the erasure technique. After compilation, all type parameters are dropped off. For example, suppose that your source code declares a parameterized type Vector<String>:

The compiled bytecode is equivalent to the following code:

So when you write a bytecode transformer, you can just drop off all type parameters. Because the compiler embedded in Javassist does not support generics, you must insert an explicit type cast at the caller site if the source code is compiled by Javassist, for example, through CtMethod.make(). No type cast is necessary if the source code is compiled by a normal Java compiler such as javac.

For example, if you have a class:

and want to add an interface Getter<T> to the class Wrapper<T>:

then the interface you really have to add is Getter (the type parameters <T> drops off) and the method you also have to add to the Wrapper class is this simple one:

Note that no type parameters are necessary. Since get returns an Object, an explicit type cast is needed at the caller site if the source code is compiled by Javassist. For example, if the type parameter T is String, then (String) must be inserted as follows:

The type cast is not needed if the source code is compiled by a normal Java compiler because it will automatically insert a type cast.

If you need to make type parameters accessible through reflection during runtime, you have to add generic signatures to the class file. For more details, see the API documentation (javadoc) of the setGenericSignature method in the CtClass.

7. Varargs

Currently, Javassist does not directly support varargs. So to make a method with varargs, you must explicitly set a method modifier. But this is easy. Suppose that now you want to make the following method:

The following code using Javassist will make the method shown above:

The parameter type int... is changed into int[] and Modifier.VARARGS is added to the method modifiers.

To call this method in the source code compiled by the compiler embedded in Javassist, you must write:

instead of this method call using the varargs mechanism:

8. J2ME

If you modify a class file for the J2ME execution environment, you must perform preverification. Preverifying is basically producing stack maps, which is similar to stack map tables introduced into J2SE at JDK 1.6. Javassist maintains the stack maps for J2ME only if javassist.bytecode.MethodInfo.doPreverify is true.

You can also manually produce a stack map for a modified method. For a given method represented by a CtMethod object m, you can produce a stack map by calling the following methods:

Here, cpool is a ClassPool object, which is available by calling getClassPool() on a CtClass object. A ClassPool object is responsible for finding class files from given class pathes. To obtain all the CtMethod objects, call the getDeclaredMethods method on a CtClass object.

9. Boxing/Unboxing

Boxing and unboxing in Java are syntactic sugar. There is no bytecode for boxing or unboxing. So the compiler of Javassist does not support them. For example, the following statement is valid in Java:

since boxing is implicitly performed. For Javassist, however, you must explicitly convert a value type from int to Integer:

10. Debug

Set CtClass.debugDump to a directory name. Then all class files modified and generated by Javassist are saved in that directory. To stop this, set CtClass.debugDump to null. The default value is null.

For example,

All modified class files are saved in ./dump.

Previous page

Java(TM) is a trademark of Sun Microsystems, Inc.
Copyright (C) 2000-2015 by Shigeru Chiba, All rights reserved.