In this article, I will show how to manipulate a compiled class file directly without decompiling it to java.

I will be using Javassist (Java Programming Assistant), an external library for most of this tutorial. Download latest JAR file to get examples work. I am using version rel_3_22_0_cr1-4-g6a3ed31.

Every java file compiled will generate a class file which is a binary file containing Java bytecode which can be executed on any Java Virtual Machine. Since the class files are generally not dependent on the platform they are compiled on, it makes Java applications platform independent. In this article, we will explore how to statically analyze class files, modify them programmatically and execute.

Sample Class for Bytecode Manipulation

We will start with a simple test class (ByteCodeEditorTest) which we will use to modify using Javassist. This class file will get an input from user and check if it matches a predefined value within code and output message accordingly.

public String checkStatus(String _inputString){
    if (_inputString.equals("MAGIC"))
        return "Right!";
    return "Wrong";
}

Once compiled, and executed below is a sample behaviour of the class. We will modify compiled class file directly to change its behaviour by modifying equality operator.

$ java ByteCodeEditorTest TEST
Wrong
$ java ByteCodeEditorTest MAGIC
Right!

Let’s start by looking at the compiled class file using javap. I have provided snippet of checkStatus() method from test class.

$ javap -c ByteCodeEditorTest
Compiled from "ByteCodeEditorTest.java"
  public java.lang.String checkStatus(java.lang.String);
    Code:
       0: aload_1
       1: ldc           #7      // String MAGIC
       3: invokevirtual #8      // Method java/lang/String.equals:(Ljava/lang/Object;)Z
       6: ifeq          12
       9: ldc           #9      // String Right!
      11: areturn
      12: ldc           #10     // String Wrong
      14: areturn
}

The disassembled code contains mnemonic for Java bytecode instructions. We will be heavily using these as a part of bytecode manipulation. Refer to Java bytecode instruction listings Wikipedia article which contains all mnemonic and Opcode for Java bytecode.

Interesting line is on index 6 from disassembled code which contains mnemonic ifeq which compares input string against built in value. Let’s use Javassist to modify equality operator from ifeq to ifne.

Bytecode Manipulation using Javassist

Now that we have our test class and details on what has to be modified in bytecode, let’s create a new class file which loads compiled ByteCodeEditorTest class for manipulation. With Javassist JAR in classpath, let’s load the test class file using javassist.CtClass.

ClassPool _classPool = ClassPool.getDefault();
CtClass _ctClass = _classPool.makeClass(new FileInputStream("ByteCodeEditorTest.class"));

Once ByteCodeEditorTest class is loaded, we will use javassist.CtMethod to extract all the methods from class and then use javassist.bytecode.CodeAttribute & javassist.bytecode.CodeIterator to manipulate the class.

CodeIterator allows us to traverse every bytecode instruction from class file and also provides methods to manipulate them. In our case, from the javap output we know index 6 has to modified to change instruction set from ifeq to ifne. Looking at Opcode reference, hex value for ifne is 9a. We will be using decimal format to update bytecode using CodeIterator.

So we will be using CodeIterator.writeByte() method to update index 6 of ByteCodeEditorTest from exising value to 154 (9a converted to decimal). Below table shows existing value (row1) and new value (row2)

Mnemonic	Opcode (Hex)	Opcode (Decimal)
ifeq	0x99	153
ifne	0x9a	154

for(CtMethod _ctMethods:_ctClass.getDeclaredMethods()){
    CodeAttribute _codeAttribute = _ctMethods.getMethodInfo().getCodeAttribute();
    CodeIterator _codeIterator = _codeAttribute.iterator();
    while (_codeIterator.hasNext()) {
        int _indexOfCode = _codeIterator.next();
        int _valueOfIndex8Bit = _codeIterator.byteAt(_indexOfCode);
        //Checking index 6 and if Opcode is ifeq
        if(_valueOfIndex8Bit==153 && _indexOfCode==6) {
            //Changing instruction from ifeq to ifne
            _codeIterator.writeByte(154, _indexOfCode);
        }
    }
}
//Write changes to class file
_ctClass.writeFile();

Once this code is run, ByteCodeEditorTest class file will be modified with updated instructions. When running javap on ByteCodeEditorTest now, it will produce below result of checkStatus() method.

$ javap -c ByteCodeEditorTest
Compiled from "ByteCodeEditorTest.java"
  public java.lang.String checkStatus(java.lang.String);
    Code:
       0: aload_1
       1: ldc           #7      // String MAGIC
       3: invokevirtual #8      // Method java/lang/String.equals:(Ljava/lang/Object;)Z
       6: ifne          12
       9: ldc           #9      // String Right!
      11: areturn
      12: ldc           #10     // String Wrong
      14: areturn
}

As you can see, index 6 is now changed to ifne. Running ByteCodeEditorTest now will produce results which we were after.

$ java ByteCodeEditorTest TEST
Right!

ByteCodeEditorTest class file was successfully modified to alter program flow without the need for re-compilation or decompilation.

While this is a simple modification to a class file, we can do complex changes of adding new methods, classes, injecting code etc. using Javassist library. I will cover complex scenarios in another article, but will give a high level overview of frequently used in APIs in next section.

Other Javassist APIs

While I covered bytecode manipulation, Javassist is a powerful library which can be used for complex changes. Highlighting some of those features here.

javassist.CtMethod class can be used to inject new methods to existing class files.

//Defrosts so that the class can be modified
_ctClass.defrost();
CtMethod _ctMethod = CtNewMethod.make("public int newMethodFromJA() { return 1; }", _ctClass);
_ctClass.writeFile();

javassist.CtMethod class can also be used to inject code to existing class/methods using insertBefore(), insertAfter() and insertAt() methods.

for(CtMethod method:_ctClass.getDeclaredMethods()){
    //Defrosts so that the class can be modified
    _ctClass.defrost();
    method.insertBefore("System.out.println(\"Before every method call....\");");
    _ctClass.writeFile();
}

Javassist can also be used for static analysis of class files by displaying all method code (disassembled) of a class file or to display bytecode of a class file.

//Display Method Code
PrintStream _printStream = new PrintStream(System.out);
InstructionPrinter instructionPrinter = new InstructionPrinter(_printStream);
for(CtMethod method:_ctClass.getDeclaredMethods()){
    System.out.println("Method: " + method.getName());
    instructionPrinter.print(method);
}
//Display Bytecode
for(CtMethod _ctMethods:_ctClass.getDeclaredMethods()){
    _ctClass.defrost();
    System.out.println("Method: " +_ctMethods.getName());
    CodeAttribute _codeAttribute = _ctMethods.getMethodInfo().getCodeAttribute();
    CodeIterator _codeIterator = _codeAttribute.iterator();
    while (_codeIterator.hasNext()) {
        int _indexOfInstruction = _codeIterator.next();
        int _indexValue8Bit = _codeIterator.byteAt(_indexOfInstruction);
        System.out.println(Mnemonic.OPCODE[_indexValue8Bit]);
    }
}

Full source code for all snippets referenced in this article is available in my github page.

While developing web applications, we will come across a lot of scenarios where we should use dynamic columns depending on the entitlement of the user or from the result set depending on the data itself. Dynamic columns in web applications give control to the user on what he wants to see (specially when we have a huge amount of data to work with). For applications with sensitive data, this can be even extended to act as a security layer where the access to specific data can be controlled with high precision.

In this article, I will explain one of the methods to implement this in any J2EE application with little or no code change.

High Level Architecture

In a nut shell, this design uses the Application Context of the container to maintain the values pertaining to a particular user, if the requirement demands not to maintain the preference after a user session is terminated, then it can be achieved by destroying the object stored in the context.

We will start by creating a singleton class, which will be used to store the user preference about the columns. The user preference object can be mapped against the user id or any other primary key, so that different preferences are maintained for different users. While the container starts, the instance for the singleton will be created. The default preferences can be loaded from a property / xml file or from a data store (DB). This object will contain the preferences of different pages with the different key names so that the same object can be used to maintain the preference across the application. This will be read during the logon operation and if the object in the application context doesn’t contain any values (if the user logs in for the first time or in an application where the preference is specific to the session) then the default values are loaded. Once the page loads, the preference can be read from the application context and can be presented to the user. If the user edits his preferences, it will be updated in the application context. Note that the application context is not persistent between container restarts, so appropriate mechanisms should be taken to store the data.

Implementation

Let’s go through the implementation now. The following steps describe how to integrate this component to an existing Struts application.

Start-up servlet and initializing the Singleton Class

Create an Initializer Servlet and make an entry for the same in the web.xml file so that the Servlet starts when the container is initialized. Make sure the load-on-startup is set to 1, which ensures that the application server loads the servlet while startup.

<servlet>
    <servlet-name> InitializerServlet </servlet-name>
    <servlet-class>com.startup.common.InitializerServlet</servlet-class>
    <load-on-startup> 1 </load-on-startup>
</servlet>

Next, create a Singleton class, which contains getter and setter methods for dynamic column preference, the object can be any collection, we are using Hash Map in this example which will be used to store the primary key against the list containing the preference. The set & get methods in the Singleton should be synchronized so that the simultaneous access is restricted. Also override the clone() method in your singleton.

public class AppSingleton implements Serializable {
    private Hashtable cusomizeViewValues = null;
    private static AppSingleton appSingleton = null;

    private AppSingleton (){ }

    public synchronized void setCusomizeViewValues (Hashtable cusomizeViewValues){
        this.cusomizeViewValues = cusomizeViewValues;
    }

    public static synchronized AppSingleton getInstance () throws Exception {
        try {
            if (appSingleton == null)
                return new AppSingleton ();
          } catch (Exception e) {
            throw new Exception();
        }
    }

    public Object clone() throws CloneNotSupportedException{
        throw new CloneNotSupportedException();
    }
}

In the startup servlet, create an instance of the singleton class. When created, the object will be available in the application context of the container, and no one will be able to create another instance, until the object created in startup is destroyed. Since we have overridden the clone method, no one will be able to clone the particular object. These measures are to ensure the integrity of the user preference stored in the singleton. A sample Initializer servlet will look like the following code.

public class InitializerServlet extends HttpServlet {
    public void init () throws ServletException {
        AppSingleton appSingleton = AppSingleton.getInstance ();
    }

    public void destroy (){}
    public void service (HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {}
}

Now, create a Data Transfer Object (DTO) / Value Object (VO) for storing the values. The VO/DTO will contain just two getters and setters, one for the Column Display name and the other for the bean property. This will be a POJO.

Populate the Application context

When the container starts, populate the list in the application context, from the property file or from the data source. If you are having a separate page to choose the columns displayed, you can use the same list to render the values initially. Similarly if the user has changed his preference then update the application context accordingly. This can be done during the Login Action, once the user is authorized and authenticated. You can use your own logic to get all the user preference and then update list with DTO’s/VO’s containing the display name and the property name. This list is updated in the application context against the primary key. Before updating the application context check if the PK is already present in the Hash Table if yes, update or create a new entry.

A sample property file will look like the one given below. By using different keys, we can have entries for different pages. Also the columns to be displayed to the user irrespective of the individual preference can also be marked here under a different key. The columns users are not allowed to modify are added to the rendering list once the request is got from the particular page and not during the logon time. The values are appended to the modifiable columns list and rendered to the user.

Validations$Optional=Plan #, Plan Name, Administrator
Validations$Core= Plan Val Description, Plan Val Status

# Optional represents the Columns users can modify
# Core represents the Columns users can’t modify

Validations$Plan#=strClientExtEntityId
Validations$PlanName=strPlanName
Validations$Administrator=strAdministrator
Validations$PlanValDescription=strDescription
Validations$PlanValStatus=strStatus

Rendering Logic

Once the values are available in the session, using JSP, logic iterate, render the Column names. Then to display the values from the result set, use the logic iterate with the list containing the values for the page, which is used to render the <tr> tag and inside that logic iterate, use another logic iterate, which is used to render the columns and use a bean define tag to get the column name properties in a scriplet variable and then use a bean define tag to display the value of the property. This logic is highly dynamic.

To display the column names,

<logic:iterate name="<Form Bean Name>" id="testId" property="<Name of the List>" >
    <td>
        <bean:write name=" testId " property="<Col Disp Name>"/>
    </td>
</logic:iterate>

To display the result set,

<logic:iterate name="<Form Name>" id="outerId" property="<Property of the Hitlist>">
    <tr>
        <logic:iterate name="<Form Name>" id="innerId" property="<Name of the List>" >
        <bean:define name="innerId" id="propId" property="<Col Property>" type="String"/>
            <td>
                <bean:write name="outerId" property="<%= propId %>" />
            </td>
        </logic:iterate>
    </tr>
</logic:iterate>

We also will have situations to display hyperlinks, textboxes etc. in the result set, the same logic can be used to display the different objects in the JSP. Just before the bean write tag, have a logic equal tag to check for specific types and render the display.

This architecture is highly customizable and can be easily plugged in into any existing J2EE application. Also this can be easily enhanced to incorporate new functionalities.