The paper "Decompiling Java Bytecode: Problems, Traps and Pitfalls" contains a small but important test program (adapted from a concatenation of 4 Java source files):

using System;
public interface Drawable {
    void draw();
}

public class Circle : Drawable {
    public int radius;
    public Circle(int r) {radius = r;}
    public bool isFat() {return false;}
    public void draw() {
        // Code to draw...
    }
}

public class Rectangle : Drawable {
    public short height, width;
    public Rectangle(short h, short w) {
        height = h; width = w; }
    public bool isFat() {return (width > height);}
    public void draw() {
        // Code to draw ...
    }
}
public class MainClass {
    public static void f(short i) {
        Circle c; Rectangle r; Drawable d;
        bool is_fat;

        if (i > 10) {                   // 6
            r = new Rectangle(i, i);    // 7
            is_fat = r.isFat();         // 8
            d = r;                      // 9
        }
        else {
            c = new Circle(i);          // 12
            is_fat = c.isFat();         // 13
            d = c;                      // 14
        }
        if (!is_fat) d.draw();          // 16
    }                                   // 17

    public static void Main(String[] args)
        { f((short) 11); }
}

The tricky thing about this program is the assignment to the local variable d, which is of type Drawable. This really tests Java decompilers, since the types of local variables is one of the two main problems that they have. However, .NET assemblies have the types of local variables, so this should be no problem for .NET decompilers.

-- MikeVanEmmerik - 07 Mar 2003