Browse Prior Art Database

Method and System for Behavioral-driven Automatic Instrumention of Classes inside a Java Virtual Machine Disclosure Number: IPCOM000186433D
Original Publication Date: 2009-Aug-20
Included in the Prior Art Database: 2009-Aug-20
Document File: 3 page(s) / 21K

Publishing Venue



A system and a related method are disclosed to automatically identify and instrument at runtime classes inside a Virtual Machine according to their characteristics (i.e. class name, implemented interfaces, access identifiers, and so on)

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 38% of the total text.

Page 1 of 3

Method and System for Behavioral-driven Automatic Instrumention of Classes inside a Java Virtual Machine

During the development and/or test of an application more and more often specific tools are used to make easier and more effective such activities. One category of such tools operates by instrumenting the application under test/debug to provide functionalities such as fault injection, profiling, monitoring and so on.

    Those tools allow usually specifying which classes/methods have to be instrumented through the use of filters. The filters generally consist in a combination of regular expression patterns and a set of attributes through which the user can select which part of the application has to be instrumented. One limitation of such kind of filters is that they do not allow selecting a class according to the interface it implements or the class it extends. This possibility can be very useful in all those situations where it is particularly difficult to identify the right classes. One example of this situation is when the classes to be instrumented have been obfuscated. In such circumstances their names are completely mangled and it is very difficult to understand their function and how they are related each other. For example the DB2 Java JDBC driver has been obfuscated and all its internal classes and methods have meaningless names (Java is a registered trademark of Sun Microsystems).

    If the intent of a test was to enable a fault injection for all the operations that access the database then a way to accomplish this would be to instrument all the classes of the JDBC driver that implement or extend at least the following classes/interfaces:


java.sql.PreparedStatement and java.sql.CallableStatement

    Without a mechanism to automatically identify and find such classes it would be very difficult for a user to debug and identify the right classes.

    In general to manage the situations described above there aren't specific systems. The current solutions are based on the fact the user of the tool has to manually identify the classes and/or the methods to be the instrumented by inspecting the structure of the application. The tools currently available in the field do not offer any capability to specify filters based on the class/interface a class has to extend/implement. And for this reason, when an application contains obfuscated code the process of manually analyze its structure is very complex and difficult to accomplish.

    The idea, proposed in this pubblication, is to exploit the new instrumentation interface provided by the most recent versions of the Java Virtual Machines to instrument a class after it has been loaded and instantiated by a class loader.

    The usual way of instrumenting classes is based on intercepting the "load class" events and to modify the bytecode of the class being loaded...