33

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();
        }
    }
}
Matthias
  • 1,153
  • 2
  • 10
  • 15
mparaz
  • 2,049
  • 3
  • 28
  • 47
  • 1
    Like it has been said: the very reason is how the private modifier is specified in the JLS. "Otherwise, if the member or constructor is declared private, then access is permitted if and only if it [the access] occurs within the body of the top level class [!!] (§7.6) that encloses the declaration of the member or constructor." So "private" always relates to the enclosing top-level-class. You have always access to everything within the top-level-class. – A Dude Mar 29 '18 at 07:33
  • 1
    There are no inner classes here. There are static nested classes. – user207421 Apr 23 '19 at 12:29

4 Answers4

34

(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.

Edit:

Yes, you can call the generated (synthetic) method, but DON'T DO THIS!:

import java.lang.reflect.Constructor;
import java.lang.reflect.Method;

public class Main
{
    public static void main(final String[] argv)
        throws Exception
    {
        final Class<?> clazz;

        clazz = Class.forName("NotPrivate$A");        

        for(final Method method : clazz.getDeclaredMethods())
        {
            if(method.isSynthetic())
            {
                final Constructor constructor;
                final Object instance;

                constructor = clazz.getDeclaredConstructor(new Class[0]);
                constructor.setAccessible(true);
                instance = constructor.newInstance();
                method.setAccessible(true);
                method.invoke(null, instance);
            }
        }
    }
}
TofuBeer
  • 60,850
  • 18
  • 118
  • 163
  • 1
    so, you declare a method private and compiler turns it public instead of generated an error? – cbrulak Mar 19 '09 at 17:29
  • 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 Mar 19 '09 at 17:32
  • package being the class that contains the inner class? – cbrulak Mar 19 '09 at 17:33
  • 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 Mar 19 '09 at 17:37
  • This answer tells something about how it is possibly done by a compiler to satisfy the jvm-spec, but not, why, what was asked for. – A Dude Mar 29 '18 at 09:25
  • And no, you do not have package level access to those private "inner" methods. If you have a separate class defined within the package, you cannot access the private methods of the nested classes from within the body of the separate class. – A Dude Mar 29 '18 at 09:30
  • A Dude, the why it is compiles requires the how the code is generated. Once you know how the code is generated it answers why it compiles. It compiles because the compiler does what it needs to do to make sure it compiles. – TofuBeer Mar 29 '18 at 23:59
  • A Dude, I updated my answer to show that, yes, you do have access to the generated (synthetic) methods. You just have to do so with reflection. – TofuBeer Mar 30 '18 at 00:01
  • You are right. One has access via reflection, but this does not help in understanding the answer to the asked question. Reflection is a way to _bypass_ access modifiers. The question is about, why you have access even at the level of java language, why the java compiler does not throw an error in the described case. – A Dude Apr 04 '18 at 07:37
  • The whole answer to the asked question simply is: The access modifier 'private' is (per specification) related to the TOP level class, not to the innermost class. This is the >why<. – A Dude Apr 04 '18 at 07:38
  • I was responding to "And no, you do not have package level access to those private "inner" methods", clearly you do. – TofuBeer Apr 06 '18 at 00:10
15

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
  • 59,820
  • 9
  • 127
  • 177
  • "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 Mar 19 '09 at 17:11
  • 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 Mar 19 '09 at 17:12
  • You are right, that was a bit misleading. Removed that part from my answer. – Eric Petroelje Mar 19 '09 at 17:20
  • 1
    @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 Mar 19 '09 at 17:30
  • @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 Mar 19 '09 at 17:34
4

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
  • 87,846
  • 14
  • 132
  • 192
0

As User 'A Dude' explained it in the comments of the accepted answer:

It compiles, because it is required to be working in that way by the language specifation, ie. the Java Lang Spec says so:

6.6.1 Determining Accessibility (at least since JLS6)

"Otherwise, if the member or constructor is declared private, then access is permitted if and only if it occurs within the body of the top level class (§7.6) that encloses the declaration of the member or constructor."

I.e. the "access-scope" of a private member is: everywhere within the lexical boundaries of the top-level class body.

That means: all private members that are defined within the class-body of the outermost class can be accessed from everywhere else in this class-body.

For instance the private method of an inner class can be accessed from methods of the outer class or from any method of another inner class of the outer class.

EternalBeginner
  • 101
  • 1
  • 9