Can I modify executed code of a static method without changing that class's code or client code?

[NadChel]

Body

Suppose we have some Main class that calls some static method of another class Foo. That method prints "foo", but let's imagine I want it to print "bar". But here's the problem: for the reasons I won't delve into, I can't modify the client code (that invokes that method directly) or the Foo code

Can I achieve my task?

I was thinking about writing a custom ClassLoader that overrides findClass() and returns a Foo proxy that prints what I want (I guess could use ByteBuddy to generate such a Class). But I'm not sure how I can make the JVM pick it up. Does it automatically take anything that extends ClassLoader and uses it? Another thing is that ClassLoaders delegate. Will my FooClassLoader simply delegate to ApplicationClassLoader that loads the "real" Foo so it won't work?

// nothing of it should be modified
public class Main {
    public static void main(String[] args) {
        Foo.printSomething();
    }
}

// this code should stay intact too
public class Foo {
    public static void printSomething() {
        System.out.println("foo");
    }
}

Guidelines

• I have read and understood this category's guidelines before making this post.

[mamoon-rasheed]

To achieve your task of modifying the behavior of the Foo class without altering the client code (the Main class) or the original Foo code, you can use Java Instrumentation. Java Instrumentation allows you to modify the bytecode of classes as they are loaded by the JVM.

[NadChel]

Can you please provide more details? Some code would be even better

[mamoon-rasheed]

Here's how you can use Java Instrumentation to intercept and modify the behavior of the Foo class:

Create an agent class that implements the java.lang.instrument.ClassFileTransformer interface. In this class, you can redefine the Foo class.

import java.lang.instrument.ClassFileTransformer; import java.lang.instrument.Instrumentation; import java.security.ProtectionDomain; import javassist.*;

public class FooAgent implements ClassFileTransformer {
public static void premain(String agentArgs, Instrumentation inst) {
inst.addTransformer(new FooAgent());
}

@Override
public byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined,
                        ProtectionDomain protectionDomain, byte[] classfileBuffer) {
    if (className.equals("Foo")) {
        try {
            ClassPool classPool = ClassPool.getDefault();
            CtClass ctClass = classPool.get("Foo");

            CtMethod printSomethingMethod = ctClass.getDeclaredMethod("printSomething");
            printSomethingMethod.setBody("{ System.out.println(\"bar\"); }");

            return ctClass.toBytecode();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    return null;
}

}

Compile the FooAgent class and create a JAR file containing this class. Also, create a manifest file specifying the Premain-Class.

When running your Java application (the Main class), use the -javaagent command-line option to specify the JAR file with your agent. For example:

java -javaagent:foo-agent.jar -cp . Main

The agent will redefine the Foo class at runtime to make the printSomething method print "bar" instead of "foo."

[NadChel]

Thank you! Can it be done using a custom ClassLoader? I would still need to pass some CLI options, wouldn't I (to make the JVM aware of my new custom loader)? If both options are valid, which is preferable, in your view?

[mamoon-rasheed]

Using a custom class loader to achieve this goal is a feasible approach, but it's more complex and less common than using Java Instrumentation. When you use a custom class loader, you indeed need to pass CLI options to make the JVM aware of your custom loader, and this approach might involve a bit more work. In my view, the Java Instrumentation approach is preferable because it's more straightforward and widely used for bytecode manipulation tasks.