tags:

views:

687

answers:

3

I don't understand why this compiles. f() and g() are visible from the inner classes, despite being private. Are they treated special specially because they are inner classes?

If A and B are not static classes, it's still the same.

class NotPrivate {
    private static class A {
        private void f() {
            new B().g();
        }
    }

    private static class B {
        private void g() {
            new A().f();
        }
    }
}
+3  A: 

Java compiles in special accessors with $ in them. So you can't write Java that access the private methods. Explained here:

http://www.retrologic.com/innerclasses.doc7.html

There is one more category of compiler-generated members. A private member m of a class C may be used by another class D, if one class encloses the other, or if they are enclosed by a common class. Since the virtual machine does not know about this sort of grouping, the compiler creates a local protocol of access methods in C to allow D to read, write, or call the member m. These methods have names of the form access$0, access$1, etc. They are never public. Access methods are unique in that they may be added to enclosing classes, not just inner classes.

Lou Franco
+9  A: 

I think this quote sums it up nicely:

...inner classes can access all members of the declaring class, even private members. In fact, the inner class itself is said to be a member of the class; therefore, following the rules of object-oriented engineering, it should have access to all members of the class.

And following from that, since both inner classes are really just part of the containing class, they should be able to access each others private members as well.

Eric Petroelje
"As a matter of fact, when your class is compiled all the inner classes are actually 'collapsed' to become part of the containing class." -- What do you mean by this?
Michael Myers
I'm pretty sure that isn't true. Usually classes of the form Outer$Inner are created. You can't really do what you said because you can have different numbers of objects of the inner and outer class.
Lou Franco
You are right, that was a bit misleading. Removed that part from my answer.
Eric Petroelje
@Eric and now the current version doesn't explains why those would have access - they are sibling classes, not contained one in the other
eglasius
@Freddy They are sibling classes, but both in the same containing class, and thus in the same scope. So, the idea is that they can access each other just as one private method in a class can call another private method in the same class.
Eric Petroelje
+8  A: 

(Edit: expanded on the answer to answer some of the comments)

The compiler takes the inner classes and turns them into top-level classes. Since private methods are only available to the inner class the compiler has to add new "synthetic" methods that have package level access so that the top-level classes have access to it.

Something like this (the $ ones are added by the compiler):

class A 
{
    private void f() 
    {
        final B b;

        b = new B();

        // call changed by the compiler
        b.$g();
    }

    // method generated by the compiler - visible by classes in the same package
    void $f()
    {
        f();
    }
}

class B
{
    private void g() 
    {
        final A a;

        a = new A();

        // call changed by the compiler
        a.$f();
    }

    // method generated by the compiler - visible by classes in the same package
    void $g()
    {
        g();
    }
}

Non-static classes are the same, but they have the addition of a reference to the outer class so that the methods can be called on it.

The reason Java does it this way is that they did not want to require VM changes to support inner classes, so all of the changes had to be at the compiler level.

The compiler takes the inner class and turns it into a top level class (thus, at the VM level there is no such thing as an inner class). The compiler then also has to generate the new "forwarding" methods. They are made at the package level (not public) to ensure that only classes in the same package can access them. The compiler also updated the method calls to the private methods to the generated "forwarding" methods.

You can avoid having the compiler generate the method my declaring the methods as "package" (the absence of public, private, and protected). The downside to that is that any class in the package can call the methods.

TofuBeer
so, you declare a method private and compiler turns it public instead of generated an error?
cbrulak
well it isn't public it is package. And, yes, that is what it does. This is because the VM has no knowledge of inner classes... so the compiler does all of the work instead of making the VM do special things.
TofuBeer
package being the class that contains the inner class?
cbrulak
package access -- accessible by all classes in the same package (namespace). It doesn't change yours, it adds another method that calls yours with a $ in it. It's not possible to call it with Java, but it can be called with bytecode you generate or maybe reflection, but I'm not sure about that.
Lou Franco