test case: public class z { public static void main(String[] args) throws Throwable { final String name = "java_cup.terminal"; Class k; ClassLoader cl = new ClassLoader(null) { }; k = cl.loadClass(name); System.out.println(k); System.out.println(k.getProtectionDomain().getCodeSource()); System.out.println(k.getClassLoader()); } } gcj gives: opsy. gcj -C z.java z.java: In class 'z$1': z.java: In constructor '(z,java.lang.String,java.lang.Object)': z.java:9: error: No constructor matching ‘(z,java.lang.String,java.lang.Object)’ found in class ‘java.lang.ClassLoader’. ClassLoader cl = new ClassLoader(null) { }; ^ 1 error This is wrong. It looks like variable capture is confusing creation of the super() call in the anonymous class constructor.
Confirmed (there might be another bug like this somewhere).
Hmm, it ICEs now on the mainline after the error, I want to say the ICE is regression.
I think the problem is the null. "null" is asscoiated with type java.lang.Object, though it here is a ClassLoader "null". A method resolution problem.
All gcj front end bugs have been fixed by the gcj-eclipse branch merge. I'm mass-closing the affected PRs. If you believe one of these was closed in error, please reopen it with a note explaining why. Thanks.