We Keep Coding

How did it achieve multiple inheritance before java 8 when there are same method signatures in interfaces

We know that if we want to achieve multiple inheritance in java we can use interfaces. If a class implements two interfaces which have the same method signature how did it achieve multiple inheritance before java 8?

You'd just implement the method, that's all. If both methods had compatible contracts (and your implementation satisfied them), then it worked out fine. If not, then your class was buggy with respect to at least one of its interfaces.
That's unchanged in Java 8. It's true even if one of the interfaces provides a default implementation -- that just means your class doesn't need to write it. But that implementation still applies to all methods with the same signature, regardless of which interface they're for.

We already know Java doesn't support Multiple Inheritance.
But It can be achieved using multiple Interfaces & Object Composition regardless of Java Version.
This can be implemented with older version of Java as well in classical way.
In this blog It is explained very well with an easy example.
https://javaterian.blogspot.com/2015/01/multiple-inheritance-in-java.html

It was a language design decision to not support multiple inheritancem (after C++): Class extends Class, but additionally introduce interfaces: Class implement Interface1, ..., InterfaceN.
The reason was the resolution of conflicting implementations in multiple parents: it simply is not logical to pick one, or even consider the conflicting method having the same meaning, semantics.
A child of List and Set would have List.add and Set.add, but would need its own add to call both. This easily leads to oversight errors und unclear APIs, and also multiple inheritance has no unavoidable and heavy use.
To your question:
class Foo<T> implements Set<T>, List<T> {
...
}
Here add is an API requirement. Most likely there is some form of delegation:
a field List<T> list = new ArrayList<>();
a field Set<T> set = new HashSet<>();
And implementing add(T) then is meaningfull, without inheritance obfuscating things: list.add+set.add.

Does Java have plan that default method (java8) Substitute for Abstract Class?

Does Java have plan that default method substitute for Abstract Class?
I could not find a real case to use default method instead of Abstract?

There are no such plans, which you can derive from comparing the already documented intentions, which differ from the implications of such a plan:
Stuart Marks writes:
The main goal is to allow interface evolution, that is, the addition of new methods. If a new method is added to an interface, existing classes that implement the interface would be missing an implementation, which would be incompatible. To be compatible, an implementation has to come from somewhere, so it is provided by default methods.
…
The main intent of a Java interface is to specify a contract that any class can implement without having to alter its position in the class hierarchy. It's true that, prior to Java 8, interfaces were purely abstract. However, this is not an essential property of interfaces. Even when default methods are included, an interface at its heart still specifies a contract upon the implementing class. The implementing class can override default methods, so the class is still in complete control of its implementation. (Note also that default methods cannot be final.)
and Brian Goetz writes:
The proximate reason for adding default methods to interfaces was to support interface evolution, …
Here are some use cases that are well within the design goals:
Interface evolution. Here, we are adding a new method to an existing interface, which has a sensible default implementation in terms of existing methods on that interface. An example would be adding the forEach method to Collection, where the default implementation is written in terms of the iterator() method.
"Optional" methods. Here, the designer of an interface is saying "Implementors need not implement this method if they are willing to live with the limitations in functionality that entails". For example, Iterator.remove was given a default which throws UnsupportedOperationException; since the vast majority of implementations of Iterator have this behavior anyway, the default makes this method essentially optional. (If the behavior from AbstractCollection were expressed as defaults on Collection, we might do the same for the mutative methods.)
Convenience methods. These are methods that are strictly for convenience, again generally implemented in terms of non-default methods on the class. The logger() method in your first example is a reasonable illustration of this.
Combinators. These are compositional methods that instantiate new instances of the interface based on the current instance. For example, the methods Predicate.and() or Comparator.thenComparing() are examples of combinators.
Note that these do not target the primary domain of abstract classes, like providing a skeleton implementation. Besides the technical differences, abstract classes are semantically different as they bear design decisions about how to implement the functionality, which interfaces, even with default methods, should not. E.g. a well-known example is the List interface, for which two fundamentally different abstract classes exist, AbstractList and AbstractSequentialList and the choice of subclasses either or implementing List entirely different should not be foreclosed by the interface. So the List interface defines the contract and can never be a substitute for an abstract class, which provides a particular base implementation.

Other answers, and links to additional materials, have already adequately covered the technical differences between interfaces and abstract classes. What hasn't been covered well is why to use one over the other.
Consider two different ways to use a class or interface in Java: as a caller or as a subclasser. A caller has an object reference and can call public methods and access public fields via that reference. A subclasser can also access, call, and override protected members of the superclass. Classes can have protected members, but interfaces cannot.
A common question seems to be, now that we have default methods, why do we need abstract classes? A default method is part of what the interface presents to callers. A protected method on a class is not available to callers; it is only available to subclassers. Thus, if you want to share implementation with subclassers, then use a class (or abstract class) and define protected members and fields.
The protected mechanism allows a class to communicate with subclassers, distinct from the way it communicates with callers.
But the OP asks the opposite question: why would one use default methods in preference to abstract classes? In the situation where you actually have a choice (i.e., your abstraction doesn't require state, or protected methods, or any of the things that abstract classes have that interfaces do not), interfaces with default methods are far less constraining than abstract classes. You can only inherit from one class; you can inherit from many interfaces. So interfaces with default methods can behave like stateless traits or mixins, allowing you to inherit behavior from multiple interfaces.
Given that interfaces and abstract classes are used for different purposes, there is no plan to remove or replace anything.

Default methods can't substitute abstract classes, as abstract classes can (and often do) have fields. Interfaces can only contain behaviour and not state, which is unlikely to change in the future as multiple inheritance of state in Java is seen (rightly or wrongly) as evil.
They can also have final methods, which is another thing you can't mimic with default methods.
If anything, interfaces with default methods resemble traits rather than abstract classes, but the match isn't perfect. Using interfaces as traits is something that has to be done very carefully and knowing the limitations they come with. (Such as any implementing class can override a default method, potentially ruining the trait.)
More on this here.

One of the reasons why default methods in interfaces were introduced was to allow adding new methods to the JDK interfaces.
Without this feature once a class has been compiled with a specific version of an interface no new methods can be added to this interface. With the default methods in interfaces feature interfaces can be changed.

Adding methods or not adding methods to interface?

In Java 8, we can have default implementations for methods in interfaces, in addition to declarations which need to be implemented in the concrete classes.
Is it a good design or best practice to have default methods in an interface, or did Java 8 come-up with that only to provide more support on older APIs? Should we start with using default methods in new Java 8 projects?
Please help me to understand what is good design here, in detail.

Prior java8, you were looking towards versioned capabilities when talking about "reasonable" ways of extending interfaces:
You have something like:
interface Capability ...
interface AppleDealer {
List<Apples> getApples();
}
and in order to retrieve an AppleDealer, there is some central service like
public <T> T getCapability (Class<T> type);
So your client code would be doing:
AppleDealer dealer = service.getCapability(AppleDealer.class);
When the need for another method comes up, you go:
interface AppleDealerV2 extends AppleDealer { ...
And clients that want V2, just do a getCapability(AppleDealerV2.class) call. Those that don't care don't have to modify their code!
Please note: of course, this only works for extending interfaces. You can't use this approach neither to change signatures nor to remove methods in existing interfaces.
Thus: just adding a new method to an interface; and having default to implement that method right there; without breaking any existing client code is a huge step forward!
Meaning: why wouldn't you use default methods on existing interfaces? Existing code will not care. It doesn't know about the new defaulted methods.

Default method in Interface has some limitations. You can not have data variables in Interface. In general the reason default methods were added for the following reason. Say in your previous version you wrote a class that implements an interface "A".In your next version you decided that it would be good idea to add a method to your interface "A". But you can not do so since any class that implements "A" now will not have that extra method and thus will not compile. This would be a MAJOR backwards compatibility breakdown. So in Java 8 you can add a default method implementation into interface so all classes that implemented old version of "A" will not be broken but will fall back on default implementation. So use this feature sparingly, only if indeed you need to expand your existing interface.

In earlier java versions it wasnt possible beacuase you had abstract classes to use concrete and declared methods only but.
Java 8 introduces “Default Method” or (Defender methods) new feature, which allows developer to add new methods to the interfaces without breaking the existing implementation of these interface. It provides flexibility to allow interface define implementation which will use as default in the situation where a concrete class fails to provide an implementation for that method.
Let consider small example to understand how it works:
public interface oldInterface {
public void existingMethod();
default public void newDefaultMethod() {
System.out.println("New default method"
" is added in interface");
}
}
The following class will compile successfully in Java JDK 8
public class oldInterfaceImpl implements oldInterface {
public void existingMethod() {
// existing implementation is here…
}
}
Why Defaut Method?
Reengineering an existing JDK framework is always very complex. Modify one interface in JDK framework breaks all classes that extends the interface which means that adding any new method could break millions of lines of code. Therefore, default methods have introduced as a mechanism to extending interfaces in a backward compatible way.
NOTE:
However we can achive this backward compatability.but its always recommended to use interfaces with delarations only that is what they are best used for.
For simple example if You have an interface Human_behaviour you can utilize all the actions of this interface like to_Walk();
to_Eat() ,to_Love(),to_Fight() say for example in every implementing class in a unique way for every human object.Like
One Human can Fight using Swords and another Object using guns and so forth.
Thus Interface is a blessing but may always be used as per the need.

With the advent of default methods in Java8's Interfaces are class adapters now possible in Java

Class Adapters uptil now have been considered not possible in java.Previous question regarding the same also says so.
But, Java 8 now supports default methods in Interfaces and multiple interfaces can be implemented by a class.
So, a class inheriting from multiple interfaces with multiple default methods can make one interface's default methods act as an adapter and make a call to the other interface's (adaptee's) default method.
So, now is the statement Java 8 supports Class Adapters correct?

As far as I understood, the Class Adapter Pattern is about creating a class which extends multiple types so that it inherits at least one implementation and at least one interface not formerly directly implemented by the implementation to enable using the existing implementation via the interface.
This has been possible in Java, with the restriction that the Adapter can only inherit one implementation (class) but inherit multiple interfaces (Compare with this answer). This limitation hasn’t changed in any way. You still can only inherit from one class.
It is correct that interfaces can now have default methods, but this doesn’t change the abstract nature of an interface and doesn’t make them eligible for conceptually bearing an implementation.
Even if an interface contains only default methods (no abstract methods), you still can’t instantiate it without creating a new class which implements the interface. Such a strange interface could only exist for primarily supporting the creation of Adapter classes which would then not be an example of the Class Adapter Pattern anymore, as that pattern is about combining formerly unrelated types, not types which were primarily designed for being combined.
In other words, in practice, when you encounter multiple implementation classes that you wish to combine in one Adapter, you will still face multiple classes which you can’t combine via inheritance and the existence of the default method feature won’t change that.
So the bottom line is, before Java 8, this pattern could only be used with restrictions, and these restrictions still apply with Java 8. If you want to view these restriction as “It’s not possible”, then it is still not possible…

Reason for adding default and static methods in interfaces

Java 8 introduced default and static methods on interfaces. So now you can have concrete implementations in your interface whether using default or static methods.
The reason Java claimed to add these two new kind of methods is "ensure binary compatibility with code written for older versions of those interfaces".
My question:
Why to distort the interface original concept that suppose to be
fully abstract in order to support existing architectural problems?
What is the difference between using an abstract class and the new version of the interface other than the ability of a class to extend multiple interfaces?

The reason java claimed to add these 2 new kind of methods is "ensure binary compatibility with code written for older versions of those interfaces".
This applies only to default methods (not static methods) and omits some context. From Goetz, State of the Lambda:
The purpose of default methods ... is to enable interfaces to be evolved in a compatible manner after their initial publication.
The main goal is to allow interface evolution, that is, the addition of new methods. If a new method is added to an interface, existing classes that implement the interface would be missing an implementation, which would be incompatible. To be compatible, an implementation has to come from somewhere, so it is provided by default methods.
Why to distort the interface original concept that suppose to be fully abstract in order to support existing architectural problems?
The main intent of a Java interface is to specify a contract that any class can implement without having to alter its position in the class hierarchy. It's true that, prior to Java 8, interfaces were purely abstract. However, this is not an essential property of interfaces. Even when default methods are included, an interface at its heart still specifies a contract upon the implementing class. The implementing class can override default methods, so the class is still in complete control of its implementation. (Note also that default methods cannot be final.)
What is the difference between using an abstract class and the new version of the interface other than the ability of a class to extend multiple interfaces?
The ability of a class to extend multiple interfaces is closely related to another difference between interfaces and abstract classes, namely that interfaces cannot contain state. This is the primary difficulty with allowing multiple inheritance: if a superclass were to appear multiple times in the ancestry of a class, would that superclass' state appear just once or several times? (This is the so-called "diamond problem.")
Another difference is that abstract classes can define methods and fields to be shared with subclasses, but not with callers, by using protected and package-private access levels. Interfaces can have only public methods.
(In Java 9, support for private methods has been added. This is useful for implementation sharing among default or static methods of an interface.)
Finally, static methods in interfaces don't affect class inheritance, nor are they part of the interface's contract. They are merely a way of organizing utility methods in more convenient fashion. For example, a common use of static methods in an interface is for static factory methods. If static methods weren't allowed in interfaces, static factory methods would have to be put on a companion class. Allowing static methods in interfaces lets such methods be grouped with the interface itself, when doing so is appropriate.

The problem is, that you can never extend an Interface with a new method without breaking compatibility. Existing classes would not implement the method and therefore not run with the new version of code which use this method.
This was a major problem for the Java Class Library itself as it cannot add often asked for methods in basic interfaces (like Collections). This was the main driver for implementing default methods for interfaces.
The difference between this new method and using an abstract class (which is a quite good pattern for this problem in some cases) is, that you cannot inherit from multiple abstract classes. But you can easily implement multiple interfaces.
The static methods in interfaces are less clear, I think they are here to help you implement the default methods (if two default methods have same code, they both can call to a static method).