In Java 8 does Interface breaks the concept of encapsulation?

Question

Till Java1.7, happily I used interfaces for implementing OOPs concept encapsulation. Means if I want to hide implementation from the end user then I will only share Interface with them and they can call my API using that interface, lets for example EJBs.

Well above was valid till Java 1.7 now in Java 8, I can write implementation of a method in Interface as well with default and static keyword, for example:

public interface Foo {

    public abstract int someUnimplementedMethod();

    default void printMsg() {
        System.out.println("Hello...!");
    }

    static void sayHello() {
        System.out.println("Hello...!");
    }

}

this is perfectly valid in Java 1.8.

Now my question is:

• In Java 8 are we trying to introduce something called partial encapsulation with default and static method?

• I know some of you will argue, if you don't want to share implementation then better to provide default and static implementation in subinterface and keep parent interface with abstract method, but now it is not sure that if I wrote an interface with abstract method, a newbie may write whole implementation in interface only. So it raises a question then better not to allow method implementation in interface.

If you disagree with my second point please provide a solution for that.

By the way I have read Java documentation which states:

Default methods enable you to add new functionality to the interfaces of your libraries and ensure binary compatibility with code written for older versions of those interfaces.

Answer 1

I would say these are additional features on top of what we had before Java 8

Like you said , its correct - there can be a default and static (available to interface only and can not be overridden.)

From oracle ,When you extend an interface that contains a default method, you can do the following

1. Not mention the default method at all, which lets your extended interface inherit the default method.
2. Redeclare the default method, which makes it abstract.
3. Redefine the default method, which overrides it.

So I don't know what to call that (partial encapsulation or not ), they are default implementation and can be overridden. Hiding actual implementation is still an feature here.

Collections in java.utils have used default methods to support lambda expressions . Now some scenarios where it can be helpful.

1. in a lot of application we need a base implementation class and then we extend that class i.e.BaseImplClass implements IsomeInterface So rather than having a BaseImplClass , you have an option of defining these default implementation in your interface, which can be overrriden if required.

2. If you have any helper or utility classes , you can use static methods in interface ...which are public,final and can not be overridden

And now if you think of diamond problem which may occur (if a class implements multiple interface with same default method signature , we will have ambiguous situation . And answer is no, you will have error at compilation time in this situation. And you must override that method.

Answer 2

Answer1: I am convinced that default methods provide partial encapsulation. Because when-ever we wrap code inside a class (now possible inside interface) encapsulation is there. Primarily it is a contemporary approach of abstraction, where we can provide what we want to do instead of how we want to do it.

Answer2: It is not a new problem, newbies can do lot danger than this. I think We can setup check-style to not allow such methods.