Posts for the month of April 2011

so long BCEL

I just pushed the de-BCEL'ed jpf-core and corresponding changes to jpf-numeric, jpf-aprop and jpf-concurrent. With this, the jpf-core runtime does not require any 3rd party libs anymore (we still use Ant and JUnit for our build system). Apart from saving about 400 BCEL classes (essentially replaced by gov.nasa.jpf.classfile.ClassFile), this also comes with a significant class load time reduction. The most important aspect however is that we can now easily deal with classfile extensions such as JSR-308.

This was a rather big change, and I expect this to take a little time to stabilize.

Nothing is for free, there are two changes that affect other JPF projects:

(1) InstructionFactory - this is now a straight forward factory pattern with dedicated factory methods such as

  public ALOAD aload(int localVarIndex) {
    return new ALOAD(localVarIndex);

To adapt to the new scheme, create a InstructionFactory class in your ...bytecode package, derive it from gov.nasa.jpf.jvm.bytcode.InstructionFactory, and override the factory methods for your own bytecodes. Don't forget to use @Override to catch typos, to make sure JPF is actually using your factory methods. Check out jpf-numeric for an example.

(2) separate classpaths - it turns out there still was a classpath crossover from the JPF classpath to the host VM native_classpath in the previous jpf-core version, which was mostly used (implicitly) from regression tests using JPF classes inside of JPF executed code. While it would be easy to reinstate under the new classfile parsing, it seems to be wise to strictly separate the two worlds. This means you now have to setup your <project>.test_classpath in your correctly. In some cases, it is more appropriate to add this directly as a "+classpath=.." argument to the verify..(jpfArgs) calls in your tests. This is somewhat annoying at first, but at least now you know where JPF gets its classes from (you can see by setting "+log.fine=gov.nasa.jpf.classfile").

Please update your projects accordingly.

upcoming BCEL replacement

this is a heads-up that the BCEL replacement is going to be pushed to babelfish within the next 10 days or so. Most projects shouldn't be affected, but if you have your own bytecode factories, those have to be changed. It becomes straight forward inheritance though, with a method per opcode. You just override the methods for your own instruction types:

public class MyInstructionFactory extends 
            gov.nasa.jpf.jvm.bytecode.InstructionFactory {
  public void astore_0() {
    add( new ASTORE(0));  // your instruction class here

more details will follow.