Yesterday, when I should have been paying attention to my breathing during yoga, I was instead thinking about inner classes. Specifically I was wondering how Java resolves ambiguities between package names and inner class names.
In Java, an inner class is specified using its parent's name, a dot, and its name. for example, Foo.Bar is an inner class named "Bar" in the parent class "Foo". But this is also how Java names packages. Bar could just as easily be a first class class in package Foo.
Note that there's no ambiguity once the code has been compiled. The class file format uses / as a package separator and $ as an inner class separator, so Foo$Bar is an inner class, and Foo/Bar is a top level class in package Foo. The ambiguity is only present in the compiler, where "." serves both purposes.
I wrote a simple test case. I created a simple Foo.java file with a public static inner class Bar, and a Foo/Bar.java file with a public class Bar. Then I wrote a test class like this:
public class Test {
public static void main(String[] args) {
System.out.println(new Foo.Bar());
}
}
What happens when you compile and run this?
peter$ java Test
Foo$Bar@c53dce
Notice the '$' in the name? The inner class won, so it looks like javac resolves the ambiguity in favour of the inner class.
But what if we really want to mess with the compiler? What happens if you try to compile this file?
public class java {
public static class lang {
public static class Object {
}
}
}
Yes, the file is called java.java. None of these names are reserved in Java, so this ought to be a perfectly legitimate class named java. It has an inner class, java.lang, with its own inner class, java.lang.Object (not to be confused with java.lang.Object, the superclass of each of these classes).
javac doesn't seem to like this class very much, at least not the version installed on my Mac:
tmp peter$ javac java.java
An exception has occurred in the compiler (1.6.0_17). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you.
java.lang.NullPointerException
at com.sun.tools.javac.comp.Flow.visitIdent(Flow.java:1214)
at com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:1547)
at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:35)
...
I don't think that this is a security hole, since the ambiguity is only present in the compiler. It's possible that there's a similar ambiguity in reflection, but I'm not sure. That might be somewhat higher risk.
Update: Eclipse compiles this java.java file with no problem. Looks like it's just an obscure bug in javac.
Further update: I'm not the first person to discover this: http://www.bodden.de/tag/name-resolution/
