Questions Why is super.super.method(); not allowed in Java?

I read this question and thought that would easily be solved (not that it isn't solvable without) if one could write:

@Override
public String toString() {
    return super.super.toString();
}

I'm not sure if it is useful in many cases, but I wonder why it isn't and if something like this exists in other languages.

What do you guys think?

EDIT: To clarify: yes I know, that's impossible in Java and I don't really miss it. This is nothing I expected to work and was surprised getting a compiler error. I just had the idea and like to discuss it.

Comments :
DayaMoon replied

Wanting to call super.super.toString() contradicts your own decision when you choose to extend a class thus accepting all (not some of) its features.


20 Answers :
Jon Skeet answered

It violates encapsulation. You shouldn't be able to bypass the parent class's behaviour. It makes sense to sometimes be able to bypass your own class's behaviour (particularly from within the same method) but not your parent's. For example, suppose we have a base "collection of items", a subclass representing "a collection of red items" and a subclass of that representing "a collection of big red items". It makes sense to have:

public class Items
{
    public void add(Item item) { ... }
}

public class RedItems extends Items
{
    @Override
    public void add(Item item)
    {
        if (!item.isRed())
        {
            throw new NotRedItemException();
        }
        super.add(item);
    }
}

public class BigRedItems extends RedItems
{
    @Override
    public void add(Item item)
    {
        if (!item.isBig())
        {
            throw new NotBigItemException();
        }
        super.add(item);
    }
}

That's fine - RedItems can always be confident that the items it contains are all red. Now suppose we were able to call super.super.add():

public class NaughtyItems extends RedItems
{
    @Override
    public void add(Item item)
    {
        // I don't care if it's red or not. Take that, RedItems!
        super.super.add(item);
    }
}

Now we could add whatever we like, and the invariant in RedItems is broken.

Does that make sense?

nice example. but i thought it's bad design when the base class accepts items, but the derived class rejects them, because the derived can't be used as a drop-in replacement for the base-class (violation of substitution principle). is that right thinking, or is such a hierarchy clean?;
Jon Skeet replied
Do you mean composition over inheritance? This example isn't a reason to avoid inheritance - although there are plenty of others.;
Jon Skeet replied
@Tim: This was just an easy-to-understand example of violating encapsulation. It could be setting a property instead. Besides, not all aspects will be visible at a type level. Generics isn't the answer to everything.;
yeah i think i agree with jon too. the superclass can very well say that behavior can be more strict in subclasses - and then the hierarchy is fine i think.;
@JohannesSchaub-litb I think that it violates Liskov substitution principle, since if one codes to the contract of Item and uses an instance of RedItems, one will get unexpected NotRedItemException. I was always taught that a sub class should take a super set of input and return a subset of output. In other words, a sub class should never reject an input that is valid for the super class or produce output that the super class cannot produce, this includes throwing an error that the super class does not throw.;
Michael Myers answered

I think Jon Skeet has the correct answer. I'd just like to add that you can access shadowed variables from superclasses of superclasses by casting this:

interface I { int x = 0; }
class T1 implements I { int x = 1; }
class T2 extends T1 { int x = 2; }
class T3 extends T2 {
        int x = 3;
        void test() {
                System.out.println("x=\t\t"+x);
                System.out.println("super.x=\t\t"+super.x);
                System.out.println("((T2)this).x=\t"+((T2)this).x);
                System.out.println("((T1)this).x=\t"+((T1)this).x);
                System.out.println("((I)this).x=\t"+((I)this).x);
        }
}

class Test {
        public static void main(String[] args) {
                new T3().test();
        }
}

which produces the output:

x=              3
super.x=        2
((T2)this).x=   2
((T1)this).x=   1
((I)this).x=    0

(example from the JLS)

However, this doesn't work for method calls because method calls are determined based on the runtime type of the object.

finnw replied
This might work, but what's it useful for?;
BalusC replied
With reflection you can do anything, yes :) You can even make strings mutable.;
Larry Watanabe replied
What a horrible thing to do! I'm giving you +1 just for figuring out how to do it at all :);
inor replied
It's a nice trick but even that is not always equivalent to calling the unavilable, yet needed) super.super and that is because the super.super call would carry the context of C (C+B+A) whereas your answers creates an instance of A without the context of B and C. So this answer will not work if every doThat called getContext(), for example, and getContext was implemented differently in each class. in your answer it would use A's getContext() whereas calling the unavailable super.super would have resulted in using C's getContext.;
Erhannis replied
Hmm. In some cases, perhaps you could overcome inor's objection with dynamic proxies (javahowto.blogspot.co.uk/2011/12/…), redirecting method calls to the original object (synchronizing variables after each call)? It seems that proxies require everything to be implementing an interface, though. Also, I wonder if it's possible for the super-super class to call one of its super-super methods, specifically, and you'd need NOT to redirect those....;
TM. answered

I don't have enough reputation to comment so I will add this to the other answers.

Jon Skeet answers excellently, with a beautiful example. Matt B has a point: not all superclasses have supers. Your code would break if you called a super of a super that had no super.

Object oriented programming (which Java is) is all about objects, not functions. If you want task oriented programming, choose C++ or something else. If your object doesn't fit in it's super class, then you need to add it to the "grandparent class", create a new class, or find another super it does fit into.

Personally, I have found this limitation to be one of Java's greatest strengths. Code is somewhat rigid compared to other languages I've used, but I always know what to expect. This helps with the "simple and familiar" goal of Java. In my mind, calling super.super is not simple or familiar. Perhaps the developers felt the same?

Tim Büthe replied
You say "not all superclasses have supers". Well, all but java.lang.Object what could give you "null". So I would say, nearly all have supers.;
finnw replied
Every class the application programmer writes has a "super" (java.lang.Object doesn't, but the application programmer doesn't write that.);
Thomas Eding replied
Easily solved by making super.super.super...super a compile time error if there are too many supers. Considering Java only has public inheritance, if someone changed the inheritance hierarchy, you are changing the interface. So I would not be not worried that super^n is scary.;
matt b answered

In addition to the very good points that others have made, I think there's another reason: what if the superclass does not have a superclass?

Since every class naturally extends (at least) Object, super.whatever() will always refer to a method in the superclass. But what if your class only extends Object - what would super.super refer to then? How should that behavior be handled - a compiler error, a NullPointer, etc?

I think the primary reason why this is not allowed is that it violates encapsulation, but this might be a small reason too.

Obviously, it would be a compiler error - and it's information that the compiler does have.;
Larry Watanabe answered

There's some good reasons to do this. You might have a subclass which has a method which is implemented incorrectly, but the parent method is implemented correctly. Because it belongs to a third party library, you might be unable/unwilling to change the source. In this case, you want to create a subclass but override one method to call the super.super method.

As shown by some other posters, it is possible to do this through reflection, but it should be possible to do something like

(SuperSuperClass this).theMethod();

I'm dealing with this problem right now - the quick fix is to copy and paste the superclass method into the subsubclass method :)

Joshua Goldberg replied
Casting before calling a method does not change the method that is delegated to—It's always the subclass' implementation that is used, never the super's. See, e.g., stackoverflow.com/questions/1677993/…;
bcr replied
@Larry this is exactly the situation I was in, and exactly the fix I used. Good call!;
Enyby replied
If you have code of needed method you can open all needed fields and run this code in your subclass.;

I think if you overwrite a method and want to all the super-class version of it (like, say for equals), then you virtually always want to call the direct superclass version first, which one will call its superclass version in turn if it wants.

I think it only makes rarely sense (if at all. i can't think of a case where it does) to call some arbitrary superclass' version of a method. I don't know if that is possible at all in Java. It can be done in C++:

this->ReallyTheBase::foo();
Larry Watanabe replied
It makes sense if someone wrote a subclass with one method implemented incorrectly but the superclass method does 90% of the work. Then you want to make a subclass, and override the method calling the superclass superclass method, and add your own 10%.;
Powerlord answered

At a guess, because it's not used that often. The only reason I could see using it is if your direct parent has overridden some functionality and you're trying to restore it back to the original.

Which seems to me to be against OO principles, since the class's direct parent should be more closely related to your class than the grandparent is.

xMichal answered

I would put the super.super method body in another method, if possible

class SuperSuperClass {
    public String toString() {
        return DescribeMe();
    }

    protected String DescribeMe() {
        return "I am super super";
    }
}

class SuperClass extends SuperSuperClass {
    public String toString() {
        return "I am super";
    }
}

class ChildClass extends SuperClass {
    public String toString() {
        return DescribeMe();
    }
}

Or if you cannot change the super-super class, you can try this:

class SuperSuperClass {
    public String toString() {
        return "I am super super";
    }
}

class SuperClass extends SuperSuperClass {
    public String toString() {
        return DescribeMe(super.toString());
    }

    protected String DescribeMe(string fromSuper) {
        return "I am super";
    }
}

class ChildClass extends SuperClass {
    protected String DescribeMe(string fromSuper) {
        return fromSuper;
    }
}

In both cases, the

new ChildClass().toString();

results to "I am super super"

xofon replied
I just found myself in a situation where I own the SuperSuperClass and ChildClass but not SuperClass, so I found the first solution useful.;
George Jempty answered

It would seem to be possible to at least get the class of the superclass's superclass, though not necessarily the instance of it, using reflection; if this might be useful, please consider the Javadoc at http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getSuperclass()

kay answered
public class A {

     @Override
     public String toString() {
          return "A";
     }

}


public class B extends A {

     @Override
     public String toString() {
          return "B";
     }

}

public class C extends B {

     @Override
     public String toString() {
          return "C";
     }

}


public class D extends C {

     @Override
     public String toString() {
          String result = "";
          try {
                result = this.getClass().getSuperclass().getSuperclass().getSuperclass().newInstance().toString();
          } catch (InstantiationException ex) {
                Logger.getLogger(D.class.getName()).log(Level.SEVERE, null, ex);
          } catch (IllegalAccessException ex) {
                Logger.getLogger(D.class.getName()).log(Level.SEVERE, null, ex);
          }
          return result;
     }

}

public class Main {

     public static void main(String... args) {
          D d = new D();
          System.out.println(d);

     }
}

run: A BUILD SUCCESSFUL (total time: 0 seconds)

Tim Büthe replied
I see, but you're creating a new instance so this wouldn't work if the object has any state.;
Ganesh Iyer answered

I have had situations like these when the architecture is to build common functionality in a common CustomBaseClass which implements on behalf of several derived classes. However, we need to circumvent common logic for specific method for a specific derived class. In such cases, we must use a super.super.methodX implementation.

We achieve this by introducing a boolean member in the CustomBaseClass, which can be used to selectively defer custom implementation and yield to default framework implementation where desirable.

        ...
        FrameworkBaseClass (....) extends...
        {
           methodA(...){...}
           methodB(...){...}
        ...
           methodX(...)
        ...
           methodN(...){...}

        }
        /* CustomBaseClass overrides default framework functionality for benefit of several derived classes.*/
        CustomBaseClass(...) extends FrameworkBaseClass 
        {
        private boolean skipMethodX=false; 
        /* implement accessors isSkipMethodX() and setSkipMethodX(boolean)*/

           methodA(...){...}
           methodB(...){...}
        ...
           methodN(...){...}

           methodX(...){
                  if (isSkipMethodX()) {
                       setSKipMethodX(false);
                       super.methodX(...);
                       return;
                       }
                   ... //common method logic
            }
        }

        DerivedClass1(...) extends CustomBaseClass
        DerivedClass2(...) extends CustomBaseClass 
        ...
        DerivedClassN(...) extends CustomBaseClass...

        DerivedClassX(...) extends CustomBaseClass...
        {
           methodX(...){
                  super.setSKipMethodX(true);
                  super.methodX(...);
                       }
        }

However, with good architecture principles followed in framework as well as app, we could avoid such situations easily, by using hasA approach, instead of isA approach. But at all times it is not very practical to expect well designed architecture in place, and hence the need to get away from solid design principles and introduce hacks like this. Just my 2 cents...

Sanjay Jain answered

@Jon Skeet Nice explanation. IMO if some one wants to call super.super method then one must be want to ignore the behavior of immediate parent, but want to access the grand parent behavior. This can be achieved through instance Of. As below code

public class A {
    protected void printClass() {
        System.out.println("In A Class");
    }
}

public class B extends A {

    @Override
    protected void printClass() {
        if (!(this instanceof C)) {
            System.out.println("In B Class");
        }
        super.printClass();
    }
}

public class C extends B {
    @Override
    protected void printClass() {
        System.out.println("In C Class");
        super.printClass();
    }
}

Here is driver class,

public class Driver {
    public static void main(String[] args) {
        C c = new C();
        c.printClass();
    }
}

Output of this will be

In C Class
In A Class

Class B printClass behavior will be ignored in this case. I am not sure about is this a ideal or good practice to achieve super.super, but still it is working.

Tim Büthe replied
Well, that's creative but doesn't really answers my question. C still doesn't call super.super, B just behaves differently. If you can change A and B you could just add another method instead of using instanceof. Super.super.foo would help you in cases where you don't have access to A and B and could not change them.;
Sanjay Jain replied
Agree @TimButhe, But if one want to call to super.super then he/she intentionally want to ignore the behavior of the parent class, so u just need to achieve that thing by existing syntax of java. (Any of option you want either instanceof / different method);
Ashtheking answered

If you think you are going to be needing the superclass, you could reference it in a variable for that class. For example:

public class Foo
{
  public int getNumber()
  {
    return 0;
  }
}

public class SuperFoo extends Foo
{
  public static Foo superClass = new Foo();
  public int getNumber()
  {
    return 1;
  }
}

public class UltraFoo extends Foo
{
  public static void main(String[] args)
  {
    System.out.println(new UltraFoo.getNumber());
    System.out.println(new SuperFoo().getNumber());
    System.out.println(new SuperFoo().superClass.getNumber());
  }
  public int getNumber()
  {
    return 2;
  }
}

Should print out:

2
1
0
Tim Büthe replied
Your exmaple is kind of... well bad, because you use static methods. When using static methods, you don't need the variable or super at all. Maybe you missed some basic OO concept here, make sure you read up on that. Have to downvote, sorry.;
Ashtheking replied
It could have easily been done without static methods. It's simple enough. I was going for a simple example on how to do this.;
Tim Büthe replied
I get your point, storing the super variable in a field is one way to solve this. But, you don't need the variable if it is a static method, you could just use it. Secondly, invoking static methods one a variable is bad practice and most IDEs will warn you about that. If you fix your answer, removing the static stuff, I'll would be glad to remove my downvote, no offense.;
Ashtheking replied
Is this better? @tim;
Tim Büthe replied
You're close, but your code will not compile. You try to access getNumber from a static context in your main method. Do you actually tried to compile this? (and should'nt your UltraFoo extend SuperFoo?);
Yonatan answered

IMO, it's a clean way to achieve super.super.sayYourName() behavior in Java.

public class GrandMa {  
    public void sayYourName(){  
        System.out.println("Grandma Fedora");  
    }  
}  

public class Mama extends GrandMa {  
    public void sayYourName(boolean lie){  
        if(lie){   
            super.sayYourName();  
        }else {  
            System.out.println("Mama Stephanida");  
        }  
    }  
}  

public class Daughter extends Mama {  
    public void sayYourName(boolean lie){  
        if(lie){   
            super.sayYourName(lie);  
        }else {  
            System.out.println("Little girl Masha");  
        }  
    }  
}  

public class TestDaughter {
    public static void main(String[] args){
        Daughter d = new Daughter();

        System.out.print("Request to lie: d.sayYourName(true) returns ");
        d.sayYourName(true);
        System.out.print("Request not to lie: d.sayYourName(false) returns ");
        d.sayYourName(false);
    }
}

Output:

Request to lie: d.sayYourName(true) returns Grandma Fedora
Request not to lie: d.sayYourName(false) returns Little girl Masha

bcr replied
ah, so you're advocating implementing a class hierarchy like this? Unfortunately, this starts to get really messy if you want to access the method in Mama from Baby (Daughter's subclass)...;
inor replied
yakov fain is right. in other words, it's not a good example, because the original question was about calling an overridden method in super.super.;
inor replied
.... and in your example GrandMa.sayYourName is not overridden;
ruruskyi answered

Calling of super.super.method() make sense when you can't change code of base class. This often happens when you are extending an existing library.

Ask yourself first, why are you extending that class? If answer is "because I can't change it" then you can create exact package and class in your application, and rewrite naughty method or create delegate:

package com.company.application;

public class OneYouWantExtend extends OneThatContainsDesiredMethod {

    // one way is to rewrite method() to call super.method() only or 
    // to doStuff() and then call super.method()

    public void method() {
        if (isDoStuff()) {
            // do stuff
        }
        super.method();
    }

    protected abstract boolean isDoStuff();


    // second way is to define methodDelegate() that will call hidden super.method()

    public void methodDelegate() {
        super.method();
    }
    ...
}

public class OneThatContainsDesiredMethod {

    public void method() {...}
    ...
}

For instance, you can create org.springframework.test.context.junit4.SpringJUnit4ClassRunner class in your application so this class should be loaded before the real one from jar. Then rewrite methods or constructors.

Attention: This is absolute hack, and it is highly NOT recommended to use but it's WORKING! Using of this approach is dangerous because of possible issues with class loaders. Also this may cause issues each time you will update library that contains overwritten class.

DayaMoon answered

I think this is a problem that breaks the inheritance agreement.
By extending a class you obey / agree its behavior, features
Whilst when calling super.super.method(), you want to break your own obedience agreement.

You just cannot cherry pick from the super class.

However, there may happen situations when you feel the need to call super.super.method() - usually a bad design sign, in your code or in the code you inherit !
If the super and super super classes cannot be refactored (some legacy code), then opt for composition over inheritance.

Encapsulation breaking is when you @Override some methods by breaking the encapsulated code. The methods designed not to be overridden are marked final.

D.Motyl answered

In C# you can call a method of any ancestor like this:

public class A
    internal virtual void foo()
...
public class B : A
    public new void foo()
...
public class C : B
    public new void foo() {
       (this as A).foo();
    }

Also you can do this in Delphi:

type
   A=class
      procedure foo;
      ...
   B=class(A)
     procedure foo; override;
     ...
   C=class(B)
     procedure foo; override;
     ...
A(objC).foo();

But in Java you can do such focus only by some gear. One possible way is:

class A {               
   int y=10;            

   void foo(Class X) throws Exception {  
      if(X!=A.class)
         throw new Exception("Incorrect parameter of "+this.getClass().getName()+".foo("+X.getName()+")");
      y++;
      System.out.printf("A.foo(%s): y=%d\n",X.getName(),y);
   }
   void foo() throws Exception { 
      System.out.printf("A.foo()\n");
      this.foo(this.getClass()); 
   }
}

class B extends A {     
   int y=20;            

   @Override
   void foo(Class X) throws Exception { 
      if(X==B.class) { 
         y++; 
         System.out.printf("B.foo(%s): y=%d\n",X.getName(),y);
      } else { 
         System.out.printf("B.foo(%s) calls B.super.foo(%s)\n",X.getName(),X.getName());
         super.foo(X);
      } 
   }
}

class C extends B {     
   int y=30;            

   @Override
   void foo(Class X) throws Exception { 
      if(X==C.class) { 
         y++; 
         System.out.printf("C.foo(%s): y=%d\n",X.getName(),y);
      } else { 
         System.out.printf("C.foo(%s) calls C.super.foo(%s)\n",X.getName(),X.getName());
         super.foo(X);
      } 
   }

   void DoIt() {
      try {
         System.out.printf("DoIt: foo():\n");
         foo();         
         Show();

         System.out.printf("DoIt: foo(B):\n");
         foo(B.class);  
         Show();

         System.out.printf("DoIt: foo(A):\n");
         foo(A.class);  
         Show();
      } catch(Exception e) {
         //...
      }
   }

   void Show() {
      System.out.printf("Show: A.y=%d, B.y=%d, C.y=%d\n\n", ((A)this).y, ((B)this).y, ((C)this).y);
   }
} 

objC.DoIt() result output:

DoIt: foo():
A.foo()
C.foo(C): y=31
Show: A.y=10, B.y=20, C.y=31

DoIt: foo(B):
C.foo(B) calls C.super.foo(B)
B.foo(B): y=21
Show: A.y=10, B.y=21, C.y=31

DoIt: foo(A):
C.foo(A) calls C.super.foo(A)
B.foo(A) calls B.super.foo(A)
A.foo(A): y=11
Show: A.y=11, B.y=21, C.y=31
user2490562 answered

It is simply easy to do. For instance:

C subclass of B and B subclass of A. Both of three have method methodName() for example.

public abstract class A {

public void methodName() {
    System.out.println("Class A");
}

}

public class B extends A {

public void methodName() {
    super.methodName();
    System.out.println("Class B");
}

// Will call the super methodName
public void hackSuper() {
    super.methodName();
}

}

public class C extends B {

public static void main(String[] args) {
    A a = new C();
    a.methodName();
}

@Override
public void methodName() {
    /*super.methodName();*/
    hackSuper();
    System.out.println("Class C");
}

}

Run class C Output will be: Class A Class C

Instead of output: Class A Class B Class C

Andrey answered
public class SubSubClass extends SubClass {

    @Override
    public void print() {
        super.superPrint();
    }

    public static void main(String[] args) {
        new SubSubClass().print();
    }
}

class SuperClass {

    public void print() {
        System.out.println("Printed in the GrandDad");
    }
}

class SubClass extends SuperClass {

    public void superPrint() {
        super.print();
    }
}

Output: Printed in the GrandDad

Jed Schaaf replied
This answer is outside of the scope of the question. The OP did not ask how to call a method in a grandparent class. The issue is a discussion of why super.super.method() is not valid code in Java.;