The BRAKES-Transformer buglist:

=> Exceptions
Currently exception handlers are not rewritten. The biggest problem is
dealing with the finally and jsr clause because these use live addresses.

=> Bugs
========
Analyzing a invoke-instruction after which a throw-statement is placed
will crash. For example:

public class Extest {

  public Extest() {}

  public void foo(int bar) {}

  public static void main(String args[]) {
    try {
      Extest t = new Extest();
      t.foo(5);
      throw new java.io.IOException();
    }
    catch (Exception ex) {}
  }
}

The underlying problem is that the way the JavaClass rewriter passes through
the instructions is totally different from the execution of it. For example
when there is an exception handler in the method code.
This means analyzing and rewriting of ExceptionHandlers can best be handled
in a different fase and that there have to be some explicit tests during the
normal analyzing and rewriting so exception-instructions won't be analyzed.
This is possible as one knows the beginning and end of each handler.

***************************

Do not use any +=, *=, -=, /= operators together with constructors. Most
Java platforms  compile these operators in such a way that makes the
rewriting of the constructor call go wrong.

A difficult categorie of problems are the java compiler optimizations.
A first problem in this categorie are the inconsistencies that appear by the
combined effects of the InvokeSpecialRewriter on one hand, and instructions
that change the stack not by pushing an element, but by inserting it in the
stack.

For example:

str += "a";

Will be compiled by the java compiler as follows:
  48 new #9 <Class java.lang.StringBuffer>
  49 dup
  50 aload_0
  51 dup_x2
  52 getfield #26 <Field java.lang.String str>
  55 invokestatic #28 <Method java.lang.String valueOf(java.lang.Object)>
  58 invokespecial #14 <Method java.lang.StringBuffer(java.lang.String)>
  61 ldc #5 <String "a">
  63 invokevirtual #19 <Method java.lang.StringBuffer
append(java.lang.String)>
  66 invokevirtual #27 <Method java.lang.String toString()>
  69 putfield #26 <Field java.lang.String str>

The particular problem here is dup_x2. The effect of this instruction is:
Before: Uninitialized StringBuffer, Uninitialized StringBuffer, This-parameter
After: This parameter, Uninitialized StringBuffer, Uninitialized StringBuffer,
	This parameter

The InvokeSpecialRewriter now moves new and dup so it executes after the
calculating of the instructions. This is why dup_x2 can't be used anymore.

Notice that you don't have this problem, when writing:

str  = str + "a";

because apparently, now the compiler doesn't use any optimization.

A solution to this problem can go two directions:
* The application programmer can't use any "+=" operators in its code when he
uses a 'new' at the right side.
* Make an overview of all instructions that change the stack. And when the
InvokeSpecialRewriter encounters such an instruction, it can't rewrite it.