Found Something Quirky: No Default Constructor in Inner Classes in Another Package?

[Perry Terrance]

One misconception that I already know about is that most people think that Java Classes with no user-defined constructor automatically create a default no-arg constructor for all classes. That statement is false.

The scenario in which this happens is in a non-static Inner Class.

For example:

com.mypackage1

public class outerClass{

protected class innerClass{

}

}

Suppose I extend outerClass to another class within the same package

com.mypackage1

public class testClass extends outerClass{

public void doMethod(){
innerClass object = new innerClass();
}

}

This doMethod code works perfectly. From what I read, transparently the Java Compiler passes the outerClass reference to a single-argument constructor of the innerClass.

The Quirky Thing though however - if I do the same exact code but put it into another package:

com.mypackage2

public class testClass extends outerClass{

public void doMethod(){
innerClass object = new innerClass();
}

}

The innerClass constructor can't be invoked like this...

Why is that?

[Hunter McMillen]

Have a look at this page from the Java tutorials about visibility and access specifiers: http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html

The answer you are looking for it near the bottom

Hunter

[Perry Terrance]

Hunter McMillen wrote:Have a look at this page from the Java tutorials about visibility and access modifiers: http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html

The answer you are looking for it near the bottom

Hunter

I think my question is going beyond the basics of visibility/access modifiers.

My InnerClass is Protected - therefore it should be able to accessed by the subclasses of OuterClass even if it in another package (com.mypackage2).

However - why is it I cannot access the transparent constructor, but the same exact construction logic in com.mypackage1 can?

[Jeff Verdegan]

Perry Terrance wrote:
My InnerClass is Protected - therefore it should be able to accessed by the subclasses of OuterClass even if it in another package (com.mypackage2).

And it is accessible. It's just the constructor that's not, because the c'tor is protected, and hence accessible only to subclasses of innerClass and classes in its package. I confirmed this with javap. I created a top-level package-private class, and its generated constructor was package-private, also confirmed with javap.

//
// protected class with protected c'tor
//
:; javap -c -classpath output/classes com.mypackage1.outerClass\$innerClass 
Compiled from "outerClass.java"
public class com.mypackage1.outerClass$innerClass extends java.lang.Object{
final com.mypackage1.outerClass this$0;

protected com.mypackage1.outerClass$innerClass(com.mypackage1.outerClass);
  Code:
   0:   aload_0
   1:   aload_1
   2:   putfield        #1; //Field this$0:Lcom/mypackage1/outerClass;
   5:   aload_0
   6:   invokespecial   #2; //Method java/lang/Object."<init>":()V
   9:   return

}


//
// package-private class with package-private c'tor
//
:; javap -c -classpath output/classes com.mypackage1.PackageClass             
Compiled from "outerClass.java"
class com.mypackage1.PackageClass extends java.lang.Object{
com.mypackage1.PackageClass();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

}

I haven't bothered to dig up the relevant part of the JLS, but it looks like compiler-generated c'tors have the same access level as their defining class.

[Perry Terrance]

Ah - this is fascinating!

So what I'm guessing is happening is this:

By specifying the innerClass as Protected, the Default Constructor for innerClass is automatically set to Protected as well.

At the OuterClass member level, the Protected innerClass itself CAN be accessed by outerClass-subclasses in BOTH com.mypackage1 and com.mypackage2.

However, the Protected Constructor of innerClass itself is one-single layer below, so it can only be access by classes in the SAME com.mypackage1, NOT by com.mypackage2.

Did I get that right?

[Jeff Verdegan]

Perry Terrance wrote:Ah - this is fascinating!

So what I'm guessing is happening is this:

By specifying the innerClass as Protected, the Default Constructor for innerClass is automatically set to Protected as well.

At the OuterClass member level, the Protected innerClass itself CAN be accessed by outerClass-subclasses in BOTH com.mypackage1 and com.mypackage2.

However, the Protected Constructor of innerClass itself is one-single layer below, so it can only be access by classes in the SAME com.mypackage1, NOT by com.mypackage2.

Did I get that right?

Yup.

Except that you didn't mention that the protected c'tor of innerClass can also be accessed by subclasses of innerClass.

EDIT: Actually, I would rephrase this whole part:

the Protected Constructor of innerClass itself is one-single layer below, so it can only be access by classes in the SAME com.mypackage1,

as simply, "The c'tor of innerClass is protected, and therefore only accessible to subclasses of innerClass and classes in the same package as innerClass."

[Perry Terrance]

Couldn't have said it better myself

and to subclass innerClass - you will have to create a new class that extends outerClass and then within it create another "inner class" that extends innerClass.

My brain is melting...

[Jeff Verdegan]

Perry Terrance wrote:
and to subclass innerClass - you will have to create a new class that extends outerClass and then within it create another "inner class" that extends innerClass.

Well, you could add a subclass of innerClass as another inner class of outerClass.

public class outerClass{

    protected class innerClass{

    }

    class inner2 extends innerClass {}
}

Or you could do something like this:

package com.mypackage2;

public class testClass extends com.mypackage1.outerClass{

    protected  class myInner extends innerClass {}
    
    public void doMethod(){
        innerClass object = new myInner();
    }

}

My brain is melting...

Yeah, mine too. Thanks for that.

[Perry Terrance]

Also - I wonder about this - shouldn't this work as well?

com.mypackage2  
      
public class testClass extends outerClass{  

protected class AnotherInnerClass extends innerClass{

public void doMethod(){  
innerClass object = new innerClass();  
}  

}
     
}  

Since AnotherInnerClass is a subclass of innerClass now, the Protected Constructor of innerClass should be accessible for all codes inside AnotherInnerClass right? However, in my Eclipse it keeps giving me a red-mark saying the innerClass constructor is not visible (which doesn't make sense....)

[Jeff Verdegan]

Perry Terrance wrote:Also - I wonder about this - shouldn't this work as well?

com.mypackage2  
      
public class testClass extends outerClass{  

protected class AnotherInnerClass extends innerClass{

public void doMethod(){  
innerClass object = new innerClass();  
}  

}
     
}  

Since AnotherInnerClass is a subclass of innerClass now, the Protected Constructor of innerClass should be accessible for all codes inside AnotherInnerClass right? However, in my Eclipse it keeps giving me a red-mark saying the innerClass constructor is not visible (which doesn't make sense....)

I think you'd get the same thing even if these weren't inner classes. Roughly speaking, the "accessible from subclass" bit of the protected access rule also includes "...but only through this. or super.".

I haven't tried to compile the below, but I think the results will be as indicated.

package a;

public class Parent {
  protected Parent() {}
  protected foo() {}
}



package b;
public class Child extends a.Parent {
  public Child() {
    super(); // ok
  }

  public void bar() {
    Parent p1 = new Parent(); // error

    Parent p2 = someLegalWayOfObtainingParent();
    p2.foo() ; // error

    foo(); // ok
  }
}

[Perry Terrance]

Jeff Verdegan wrote:
I think you'd get the same thing even if these weren't inner classes. Roughly speaking, the "accessible from subclass" bit of the protected access rule also includes "...but only through this. or super.".

Interesting - this is first time I ever heard of this unique constraint of the Java language. And frankly - I find it kind of odd this constraint doesn't happen when all the code in the same package - ergo:

    
com.mypackage1  
      
public class testClass extends outerClass{  
      
public void doMethod(){  
innerClass object = new innerClass();  //Works Fine - innerClass declaration detected as well as instantiation-constructor detected
}  
      
}  

[Jeff Verdegan]

Perry Terrance wrote:

Jeff Verdegan wrote:
I think you'd get the same thing even if these weren't inner classes. Roughly speaking, the "accessible from subclass" bit of the protected access rule also includes "...but only through this. or super.".

Interesting - this is first time I ever heard of this unique constraint of the Java language.

I think that the usual way people access protected methods is through super or this anyway, so it often doesn't come up, or doesn't come up until later in one's Java career.

And frankly - I find it kind of odd this constraint doesn't happen when all the code in the same package - ergo:

Because protected means "accessible by subclasses and classes in the same package," and the "in the same package" part doesn't care about accessing through super or this. That's only relevant when accessing via a subclass.