The paper [[http://www.sable.mcgill.ca/publications/papers/#cc2002-2 "Decompiling Java Bytecode: Problems, Traps and Pitfalls"]] contains this small but important test program (concatenation of 4 Java source files):
<verbatim>
public class Circle implements Drawable {
	 public int radius;
	 public Circle(int r) {radius = r;}
	 public boolean isFat() {return false;}
	 public void draw() {
		  // Code to draw...
	 }
}

public class Rectangle implements Drawable {
	 public short height, width;
	 public Rectangle(short h, short w) {
		  height = h; width = w; }
	 public boolean isFat() {return (width > height);} 
	 public void draw() {
		  // Code to draw ...
	 }
}
public interface Drawable {
	 public void draw();
}

public class Main {

	 public static void f(short i) {
		  Circle c; Rectangle r; Drawable d;
		  boolean 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); }
}
</verbatim>
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.

-- Main.MikeVanEmmerik - 13 Feb 2003