Bytecode Instrumentation (BCI) is a technique for adding bytecode to a Java class during “runtime.” It’s not really at runtime, but more during “load” time of the Java class.we write Java code—e.g., create a *.Java file—we compile the code—e.g., creating a *.class file, which is written in bytecode, and when we execute it, an interpreter—the Java.EXE—is responsible for actually executing the commands written in the bytecode format within the *.class file. As with any interpreter, since we are not dealing with real object code, one can manipulate the actual code written in the executed file. I want to add functionality to a Perl/PHP/JSP/ASP code—that’s easy. We could simply open the file in a text editor, change the code, and next time it was executed it would behave differently. we could easily write a program that changes the code back and forth as we wish as a result of some user interface activity. With bytecode, it’s the same concept, only a bit trickier. Try to open bytecode in a text editor—not something we want to work with…but still possible.Anyhow, the way to manipulate the actual bytecode is by intervening during the class loading flow and changing the code on the fly. Every JVM (Java Virtual Machine) will first load all the class files (sometime it will do it only when really required, but that doesn’t change the following description) to its memory space, parsing the bytecode, and making it available for execution. The main() function, as it calls different classes, is actually accessing code which was prepared by the JVM’s class loaders. There is a class loader hierarchy, and there is the issue of the classpath but all that is out of the scope of So the basic concept of bytecode instrumentation is to add lines of bytecode before and after specific method calls within a class, and this can be done by intervening with the class loader. Back in the good old days, with JDK <1.5, we needed to really mess with the class loader code to do that. From JDK 1.5 and above, Java introduced the Java agent interface, which allows writing Java code that will be executed by the class loader itself, thus allowing the manipulation of the bytecode within every specific class, and making the whole process pretty straightforward to implement, thus the zillion different products for Java profiling and “transaction management” for Java applications.