JXCL and UCovered

JXCL is a framework for constructing instrumenting class loaders and other transformation and software generation tools for Java.

UCovered is a Java unit test and coverage tool built around JXCL. It modifies Java classes as they are loaded, working at the bytecode level instead of on source code.

The JXCL core is designed to accept any number of transformers. These can report on the code at various levels or transform it.

JXCL is written in Java, and so can run anywhere. It has been developed on Linux systems, but tested on a wide range of hosts. Certain parts of the framework use Apache's ByteCode Engineering Library (BCEL) and are written in what amounts to assembly language, but the BCEL is in Java and so all of the software is portable.

The software is currently in near-beta state. There is one known bug. The JXCL core has been stable for some time.

We are looking for developers of add-on modules. These might, for example, do method call tracing, performance testing, or implement Aspects.

There are several other software projects providing some of JXCL's functionality, but so far as we know none have its modular form, none are so easily extensible.

UCovered and Coverage

The primary near-term objective of the JXCL Project is the development of UCovered, a tool for measuring coverage in the testing of Java programs. Coverage is a measure of the extent to which tests exercise the code under test.

The simplest measure of coverage is statement coverage. For example, if there are 100 lines in a program and only 75 are actually used when tests are being run, then the coverage may be said to be 75%.

This is a simple but very significant check on the testing being done. If 75% of the code is covered, then 25% isn't: you don't know whether 25% of your application works.

UCovered's coverage measurements can't actually help you write better tests or better code. But they can tell you whether or not your code is being tested.

How It Works

JXCL intercepts code as it is being loaded and alters it. It doesn't work at the source code level. It manipulates compiled classes and their bytecode, the machine code of the Java Virtual Machine, the JVM.

To measure coverage, UCovered inserts instrumentation, typically bytecode that increments counters whenever a block of code or branch is executed. This is done transparently. The programmer simply sets a switch at test time. Then when program modules are loaded for testing, JXCL instrumentation is automatically added and coverage reports generated.

Using UCovered with Other Software Development Tools

UCovered is used with the JUnit unit test program. Typically you will run unit tests under they succeed. Then, when the debugging is largely done, you run UCovered coverage checks as well as JUnit unit tests. If the UCovered run shows that you need more testing, if coverage is too low, you add more tests or alter the ones that you have until you are satisfied with the level of coverage.

One of the objectives of the UCovered project is full JUnit interoperability, in that sense that the interface to UCovered should be a superset of the JUnit interface. If you are used to working with JUnit, you should be able to work with UCovered in exactly the same way.

UCovered and JUnit can also be used in conjunction with Ant, Java's equivalent of the make command-line build facility. UCovered's Ant task, the module interfacing Ant with UCovered and JUnit is complete and available either via CVS or in tarball form.

As you can see from inspecting the UCovered distribution, the Maven project management software package has also been used in developing UCovered. Maven is used primarily for Web site and project documentation generation. UCovered is being integrated back into Maven as part of the development effort; that is, a UCovered goal for Maven is in development.

In the somewhat longer term, we expect to integrate UCovered into other software development packages, in particular into the Eclipse IDE. However, work on this has not yet begun.

Other Applications

JXCL does its magic using a variety of tools. These include

  • transforming class loaders, which load a compiled Java class and change it in some way, typically while leaving its basic functionality unchanged
  • instrumenting class loaders, a special case of transforming loaders which insert counters and other blocks of bytecode for monitoring program behavior
  • a class synthesizer, which builds a class at run time, from a description, rather than loading it from disk
  • tools for generating and modifying method control flow graphs
  • report generation facilities

These and other JXCL components can be used to build other tools for monitoring and modifying Java code at run time.