In previous installments of this series I've concentrated on the -javaagent parameter for agent access. In this installment I'll introduce another way to access the inner workings of a JVM via an undercover agent; the -agentpath and -agentlib parameters.

As prevously presented, agent access was obtained via a Java class that was loaded early in the JVM startup sequence. This class had access to many areas of the JVM, but not all. By using an 'undercover' agent, access to much more fine-grained behavior can be obtained - but at a price.

In part 1 of this series, I gave an overview of Java agents and bytecode manipulation and provided a simple agent that adds a System.out.println() message to a method. In part 2, I provided an agent that eliminates calls to log4j log methods in designated packages and log levels. In part 3, I'll show how to augment code to help analyze stack traces by introducing an agent that keeps track of how many instrumented methods are called by each thread.

In my previous blog entry Not-So-Secret Java Agents, Part 1, I gave an introduction to the concepts behind Java agents and provided a simple example that dynamically added a System.out.println() message to a method. In this installment I'll amp up the complexity by implementing an agent that dynamically and selectively eliminates log4j calls.

A little-known option to recent Java VMs holds a fair amount of mystery and quite a lot of power. That option is 'javaagent', and it holds the key to monitoring and profiling JVMs and being able to dynamically modify Java classes as they're being loaded.