Stopping Your Class from Being Inherited in Java, the Official Way and the Unofficial Way

The Official Way

Officially, the Java language provides the keyword ‘final’ that is supposed to fulfill this task. Consider the following code sample:

//FinalDemo.java
public final class FinalDemo {

}

Let’s make another class that is supposed to be inherited from the above class. The Java language provides the ‘extends’ keyword that enables a class to be inherited from an existing class.

//FinalDemo2.java
public class FinalDemo2 extends FinalDemo {

}

After compiling the first class, if you compile the second class, the JDK compiler will complain and you will get following error message:

FinalDemo2.java:1: cannot inherit from final FinalDemo
public class FinalDemo2 extends FinalDemo{}
                                ^
1 error

You have stopped your first class from being inherited by another class, the official way.

The Unofficial Way

But, that’s not the only way to stop your class from being inherited by some other class. Consider the following code where I declare the constructor as private, and I declare a static method that returns an object of the class:

public class PrivateTest{
        private PrivateTest(){
                System.out.println("Private Default Constructor");
        }
        public static PrivateTest getInstance(){
                return new PrivateTest();
        }

}

A modified form of the above code is also known as the “Singleton Pattern,” where the getInstance method always returns only one instance of the class. But why does this code stop this class from being inherited? Consider the following code that is supposed to be inherited from the above class:

public class PrivateTest2 extends PrivateTest{


}

After compiling the first class, if you compile the second class, the JDK compiler will complain and you will get the following error message:

PrivateTest2.java:1: PrivateTest() has private access in PrivateTest
public class PrivateTest2 extends PrivateTest{
       ^
1 error

The second class is unable to inherit the first class. But what does this error mean? The Java language makes it compulsory to provide at least one constructor in your class. If you do not provide any constructor in your class, the JDK compiler will insert the so-called default constructor in your class; in other words, that constructor with no arguments, with an empty body, and with a public access modifier. But if you define a constructor by yourself, the JDK compiler will not insert a default constructor for you. What we did in class PrivateTest was that we declared the default constructor, but we changed the access modifier to private, which is legal by the rules of JDK compiler.

Now comes the second part. The Java language also makes it compulsory that you put the call to the super class constructor as the first call in your constructor. This is necessary to enable the inheritance features. We achieve this functionality by calling the appropriate super() method in Java, that should map to appropriate super class constructor. If you do not provide a default constructor, than JDK compiler will insert a default super constructor call in your constructor.

What I did in the first class that I make the constructor private. Now, when I inherit that class in the other class, the compiler tries to put in the default super constructor call. Because the scope of the super class constructor is set to private, the compiler complains that it is unable to call the super constructor. Hence, we stopped a class being inherited by some other class, the unofficial way.

Dealing With the Diamond Problem in Java

In Java, an interface or class can extend multiple interfaces. For example, here is a class hierarchy from java.nio.channels package:

Image title

The base interface is Channel. Two interfaces, ReadableByteChannel and WriteableByteChannel, extend this base interface. Finally, ByteChannel interface extends ReadableByteChannel and WriteableByteChannel.  Notice that the resulting shape of theinheritance hierarchy looks like a “diamond.”

In this case, the base interface Channel does not have any methods. The ReadableByteChannel interface declares read method and the WriteableByteChannel interface declares write method; the ByteChannel interface inherits both read and write methods from these base types. Since these two methods are different, we don’t have a conflict and hence this hierarchy is fine.

But what if we have two method definitions in the base types that have the same signature; which method would the ByteChannel interface inherit? When this problem occurs it is known as “diamond problem.”

Fortunately, rules are available to resolve methods when a derived type inherits method definitions with the same name from different base types. Let us discuss two important scenarios here.

Scenario 1: If two super interfaces define methods with the same signature, the compiler will issue an error. We have to resolve the conflict manually.

//Diamond.java

interface Interface1 {
default public void foo() { System.out.println(“Interface1’s foo”); }
}

interface Interface2 {
default public void foo() { System.out.println(“Interface2’s foo”); }
}

public class Diamond implements Interface1, Interface2 {
public static void main(String []args) {
new Diamond().foo();
}

Error:(9, 8) java: class Diamond inherits unrelated defaults for foo() from types Interface1 and Interface2

In this case, resolve the conflict manually by using the super keyword within the Diamond class to
explicitly mention which method definition to use:

 public void foo() { Interface1.super.foo(); }

After this method definition is added in the Diamond class and executed, this program prints: Interface1’s foo

Scenario 2: If a base class and a base interface define methods with the same signature, the method definition in the class is used and the interface definition is ignored.

class BaseClass {
public void foo() { System.out.println(“BaseClass’s foo”); }
}

interface BaseInterface {
default public void foo() { System.out.println(“BaseInterface’s foo”); }
}

public class Diamond extends BaseClass implements BaseInterface {
public static void main(String []args) {
new Diamond().foo();
}
}

No compiler error in this case: the compiler resolves to the definition in the class and the interface definition is ignored. This program prints “Base foo”. This can be considered as “class wins” rule. This rule helps maintain compatibility with versions prior to Java 8. How? When a new default method is added in an interface, it may happen to have the same signature as a method defined in a base class. By resolving the conflict by “class wins” rule, the method from the base class will always be selected.