tcltest::test 13.1-constructor-1 { Constructors in a non-private non-static
        nested class have an additional first parameter in the binary, for
        the enclosing class } {
    empty_class T131c1a {
	class Inner {}
    }
    delete T131c1a.java
    compile -classpath . [saveas T131c1b.java {
class T131c1b {
    Object o = new T131c1a().new Inner();
}
    }]
} PASS

tcltest::test 13.1-covariance-1 { Class files may have more than one method
        with the same parameter types but different return types. In
        particular, legal .class files compiled with gj (generic java) or the
        JSR14 beta compiler (the prequel to the expected JDK 1.5) allow
        covariance in return types, and do so by compiling synthetic bridge
        methods. Here, we check that the compiler is able to gracefully handle
        covariance when loading a .class file, even though this is normally
        a binary incompatible change. } {
    compile [saveas T131co1a.java {
class T131co1a {
    T131co1b m() { return null; }
}
class T131co1b extends T131co1a {
    T131co1b m() { return null; }
}
class T131co1c extends T131co1b {
    { m(); }
}
    }]
    delete T131co1a.java
    compile -classpath . [saveas T131co1a.java {
class T131co1a {
    T131co1a m() { return null; } // change return type to a instead of b
}
// class T131co1b extends T131co1a {
//     T131co1b m() { return null; } // now covariant!
    // if this class were uncommented and compiled by gj, it would also have
    // /*synthetic*/ T131co1a m() { return /*T131co1b*/m(); }
// }
class T131co1c extends T131co1b {
    { m(); }
}
    }]
} PASS

tcltest::test 13.1-covariance-2 { Class files may have more than one method
        with the same parameter types but different return types. In
        particular, legal .class files compiled with gj (generic java) or the
        JSR14 beta compiler (the prequel to the expected JDK 1.5) allow
        covariance in return types, and do so by compiling synthetic bridge
        methods. Here, we check that the compiler is able to gracefully handle
        covariance when loading a .class file, even though this is normally
        a binary incompatible change. } {
    compile [saveas T131co2a.java {
class T131co2a {
    T131co2b[] m() { return null; }
}
class T131co2b extends T131co2a {
    T131co2b[] m() { return null; }
}
class T131co2c extends T131co2b {
    { m(); }
}
    }]
    delete T131co2a.java
    compile -classpath . [saveas T131co2a.java {
class T131co2a {
    T131co2a[] m() { return null; } // change return type to a[] instead of b[]
}
// class T131co2b extends T131co2a {
//     T131co2b[] m() { return null; } // now covariant!
    // if this class were uncommented and compiled by gj, it would also have
    // /*synthetic*/ T131co2a[] m() { return /*T131co2b*/m(); }
// }
class T131co2c extends T131co2b {
    { m(); }
}
    }]
} PASS

tcltest::test 13.1-covariance-3 { Class files may have more than one method
        with the same parameter types but different return types. In
        particular, legal .class files compiled with gj (generic java) or the
        JSR14 beta compiler (the prequel to the expected JDK 1.5) allow
        covariance in return types, and do so by compiling synthetic bridge
        methods. Here, we check that the compiler is able to gracefully handle
        covariance when loading a .class file, even though this is normally
        a binary incompatible change. } {
    compile [saveas T131co3a.java {
interface T131co3a {
    T131co3b m();
}
interface T131co3b extends T131co3a {
    T131co3b m();
}
abstract class T131co3c implements T131co3b {
    { m(); }
}
    }]
    delete T131co3a.java
    compile -classpath . [saveas T131co3a.java {
interface T131co3a {
    T131co3a m(); // change return type to a instead of b
}
// interface T131co3b extends T131co3a {
//     T131co3b m(); // now covariant!
// }
abstract class T131co3c implements T131co3b {
    // if b were uncommented and compiled by gj, this class would also have
    // /*synthetic*/ T131co3a m() { return /*T131co3b*/m(); }
    // Note that calling a.m() may fail when this class is not compiled by
    // gj, as the bridge method is missing; but that is a different problem.
    { m(); }
}
    }]
} PASS
