We Keep Coding

When to use interface vs abstract class after Java 8

I know this question has been asked many times and we have articles all over the internet but I still cannot fully understand, when should I use interface or abstract class since I am using Java 15.
Most of the articles talk about the differences and use cases before Java 8 which makes sense but not when you can basically provide body for your methods in interface.
The only thing that made sense to me is non-public and non-final restrictions.
I would really appreciate if somebody can point out 1-2 examples of the scenarios where I need to choose between interface and abstract class in Java 15. Also, would be great if it can be in terms of real life projects rather than Animal or shape class examples.
Thanks !!

default methods on interface
Apparently you are referring to the feature of “default methods” implementing behavior in an interface.
You should understand that the feature was added as a way around this dilemma: How to retroactively add features leveraging streams and lambda on existing interfaces without breaking existing classes that implement those interfaces?
Many new methods were added to those interfaces such as in the Java Collections Framework. Adding methods to an existing interface would automatically break all classes implementing the interface that are lacking the newly-required methods. Being able to provide a fallback, to give an implementation where one is now required but not yet existing, would resolve the dilemma. Thus « default methods » were born.
To quote from the Oracle tutorial linked above:
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.
To quote this Answer by Brian Goetz, Java Language Architect at Oracle:
The proximate reason for adding default methods to interfaces was to support interface evolution
So this feature of adding default behavior to an interface was not meant to be a new mainstream feature in and of itself. The intent of default was not to replace abstract.
Indeed, some experienced Java experts have recommended against making a habit of writing default methods on an interface. They recommend pretty much ignoring that feature of the Java language. Continue to think of interfaces as simply defining a contract, and abstract classes as providing partial implementations meant to be completed in a subclass.
You are certainly free to write your own default methods on your interfaces. And certainly you should do so if you are in a similar situation of having published an interface that others may have implemented, and now you want to add methods. But unnecessarily adding default methods is likely to confuse other programmers who expect partial implementations on an abstract class rather than an interface.
Four situations calling for default method on an interface
In that same post linked above, Brian Goetz suggests three other cases beyond interface evolution where default methods on an interface may be appropriate. Here is a quick mention; see his post for details.
Optional methods - The default method throws an UnsupportedOperationException because we expect implementations of this interface to more often not want to implement this method.
Convenience methods
Combinators
Start with interface, move to abstract class for shared code
As for choosing between an interface and abstract class:
Generally start with an interface. Or several interfaces if you want various implementing classes to mix various contracts (see mixin).
Think twice before adding a default method. Consider if your situation meets one of the four cases recommended by Brian Goetz as discussed above.
If you come to realize that you have duplicated code across multiple classes, then consider centralizing that shared code to an abstract class to be used across subclasses.
Alternatively, use composition rather than inheritance (discussed below).
For example, you might have a class for domestic ShippingLabelUS as well as ShippingLabelCanada and ShippingLabelOverseas. All three need to convert between imperial pounds and metric kilograms. You find yourself copying that code between the classes. At this point you might consider having all three classes extend from abstract class ShippingLabel where a single copy of the weight conversion methods live.
While designing your API keep in mind that Java, like most OOP languages, has single-inheritance. So your subclasses are limited to extending only one class. To be a bit more specific about the single-versus-multiple inheritance, I will quote Brian Goetz from this PDF of a slide deck:
[regarding default methods on an interface]
Wait,is this multiple inheritance in Java?
• Java always had multiple inheritance of types
• This adds multiple inheritance of behavior
• But not of state, where most of the trouble comes from
Composition over inheritance
An alternative to using an abstract class for shared behavior is creating a separate class for specific behavior, then adding an object of that separate class to be kept as a member field on the larger class. Wise programmers often share this pearl of wisdom: Prefer composition over inheritance.
Regarding the shipping label example above, you could create a WeightConverter class, an object of which would be a member of each of the three label classes. In this arrangement, no need for the abstract class.

UML: Java Defender or Default Methods

Since the release of Java 8 you may provide default implementations of methods in interfaces.
I have been looking for a way to realize this in UML but could not find anything on the matter. The case of default implementations in interfaces probably is too special to be adopted to in the UML specs.
But still the Question:
Is there a way to display these default methods in UML?

There is nothing special about this situation from UML perspective, that's what stereotypes are for.
UML represents a conceptual model, which is not tied to a language-specific situation, so you can model it for example in this way:
How such model will be implemented is different matter. In Java you could use interfaces, in C++ (which doesn't have interfaces) you would abstract classes, in Ruby you might take a yet different approach, but the model can** still be the same.
**By can I mean that it is common practice to commit to a particular language already at the modeling level, so one would alter to model to better fit the target language.

There are three types of methods within an interface in java 8:
static
default
abstract
Abstract methods are generally italic
+ sayAbstract() : void
Static methods are generally u̲n̲d̲e̲r̲l̲i̲n̲e̲d̲:
+̲ ̲s̲a̲y̲S̲t̲a̲t̲i̲c̲(̲)̲ ̲:̲ ̲v̲o̲i̲d̲
Since default methods are a sort of instance methods, format them accordingly:
+ sayDefault() : void

Does really interfaces can be use to achieve multiple inheritance

I have this confusion for long time. Many people says we can achieve multiple inheritance by interfaces in languages like C# or Java which does not support it like C++ does. But my understanding of inheritance and interface says no. Because interfaces are contracts to validate an implementation which has nothing to do with behavior. Interface defines what something can do (not what something is). But inheritance is inheriting behavior and/or property from parents (like a child is getting some genetic behavior from his parent - which is inheritance). Now the child is learning a skills say painting and cooking and the interface (a certificate or contract) acts as a validation that the child is having such skills (that is what the child can do other than what he got from his parents - and that's not inheritance)
So am I understanding it wrong? And if not then why it is saying that we can achieve multiple inheritance using interfaces?

Interfaces give you multiple inheritance of a type, but not behaviour. A class implementing List and Map is a "ListMap", but the implementation has nothing (necessarily) to do with any existing List or Map implementation.
Of course using composition (which should be favored anyways), you could easily create a ListMap which delegates the calls accordingly to its list and map properties, while providing some presumably useful function that would combine their respective data.
With Java 8 interfaces are allowed default methods, so inheritance of behaviour is now also possible.

In Java you can create an interface for example Animal and an abstract class Bird.
then you can have a class MockingBird which extends the behavior of Bird and implements the actions of an Animal.
However, you can then address MockingBird as an Animal or as a Bird because it "inherits" from both.

No, interfaces cannot be used to achieve multiple inheritance
Not at all in Java, in C#, we can get closer.
I studied this matter when I wanted to implement an observer, and ended up in Robert Martin's blog: http://blog.cleancoder.com/uncle-bob/2015/01/08/InterfaceConsideredHarmful.html
After reading this post I realized he's talking about Java, but C# supports extension methods which allow you to attach behaviour on interfaces so I tried to make my implementation on some IObservable interface but obviously failed, even if I can attach behaviour in such interfaces extension methods I'm still not allowed for attaching state on them, if some day microsoft decides to implement extension properties then this combination (Interface + Extension methods + Extension properties) could be sufficient to truly simulate some useful multiple inheritance.
For now, we are stuck with duplicating the code, or the delegation code in all our observers as stated in the blog.

Handling Shared Data

To develop a fully functional application consisting of more than 4 classes, what is the right way of handling shared data? I have researched about Static Methods and variables and Utility classes. It's said that use of Static methods hinders the concept of Object Orientation concept. So, if anybody could help me on how to use shared data between classes without hindering Object Oriented concept, then I would be highly grateful.

There are two primary axes of "inheritance" in object-oriented languages like Java. "Implementation" inheritance is where the sub-class inherits the actual code implementation from the parent. "Interface" inheritance is where the "sub-class" adheres to the public interface of the "parent".
Alas, Java actually mixes the two notions together a bit... Java interfaces are nice and clean -- when you "implement" an interface, you are stipulating that your class adheres to the "contract" of the interface that you specified. Java class inheritance isn't so clean -- when you sub-class in Java you are getting both the code inheritance but you are also stipulating that your sub-class adheres to the "contract" of the interface of the parent class.
Abstract classes in Java are just like regular Java classes but with the added constraint that you cannot instantiate them directly. In terms of that added constraint, they are basically classes which don't actually implement all of the code specified by their "contract".
So, it's generally considered good OO practice to specify the "contract" which you want to adhere to via Java interfaces. Then use normal Java class inheritance primarily for code reuse purposes. Use abstract Java classes when you want to provide some standard base code but want/need to force the user's of your class to complete the implementation (i.e., you create a skeleton implementation and the sub-classes must flesh it out).

Why make Abstract classes and Interfaces?

Well I was going to ask what the difference is but it's been answered before. But now I'm asking why did they make these differences? (I'm speaking about java here, I don't know if the same applies to other languages)
The two things seem very similar. Abstract classes can define a method body whilst interfaces can't, but multiple interfaces can be inherited. So why didn't they (by 'they' I mean Sun when they wrote Java) make one thing where you can write a method body and this type can be inherited more than once by a class.
Is there some advantage in not being able to write a method body, or extend multiple times that I'm not seeing?

Because allowing classes to inherit multiple implementations for the same method signature leads to the obvious question, which one should be used at runtime.
Java avoids this by supporting multiple inheritance only for interfaces. The signatures declared in each interface can be combined much more easily (Java basically uses the union of all methods)

Multiple inheritance in C++ leads to semantic ambiguities like the diamond inheritance problem. MI is quite powerful, but has complex consequences.
Making interfaces a special case also raises the visibility of the concept as a means of information hiding and reducing program complexity. In C++, defining pure abstract bases is a sign of a mature programmer. In Java, you encounter them at a much earlier stage in the evolution of a programmer.

Multiple inheritance is more difficult to implement in a language (compiler really) as it can lead to certain issues. These issues have been discussed here before: What is the exact problem with multiple inheritance.
I've always assumed this was a compromise in Java. Interfaces allow a class to fulfill multiple contracts without the headache of multiple inheritance.

Consider this example:
public abstract class Engine
{
public abstract void switchPowerOn();
public abstract void sprinkleSomeFuel();
public abstract void ignite();
public final void start()
{
switchPowerOn();
sprinkleSomeFuel();
ignite();
}
}
Abstract class can help you with having solid base methods which can or cannot be overriden, but in these methods it uses abstract methos to provide you an opportunity to do your specific thing. In my example different engines have different implementations of how they switch power on, sprinkling some fuel for the ignition, and doing the ignition, however the starting sequence of the engine stays always the same.
That pattern is called "Form Template Method" and is quite frankly the only sensible usage of abstract classes in Java for me.

Making them one thing is the route that the Scala guys took with Traits which is an interface that can have methods and supports multiple inheritance.
I think interfaces, for me, are clean in that they only specify requirements (design by contract) whereas abstract classes define common behaviour (implementation), so a different tool for a different job? Interfaces probably allow more efficient code generation during compile time as well?

The other approach you are describing is the approach used by C++ (mixins for example). The issues related to such "multiple inheritance" are quite complex, and has several critics in C++.

Inheritance means you inherit the nature (meaning) and responsibility (behaviour) of the parent class, while interface implementation means you fulfill a contract (e.g. Serializable), which may have nothing to do with the core nature or responsibility of the class.
Abstract class let you define a nature that you want to be generic and not directly instanciable, because it must be specialized. You know how to perform some high-level tasks (e.g. make a decision according to some parameters), but you don't know the details for some lower-level actions (e.g. compute some intermediary parameters), because it depends on implementation choices. An alternative for solving this problem is the Strategy design pattern. It is more flexible, allowing run-time strategy switching and Null behaviour, yet it is more complex (and runtime swtiching is not always necessary). Moreover, you might lose some meaning & typing facilities (polymorphism & type-checking becomes a bit harder because the Strategy is a component, not the object itself).
Abstract class = is-a, Strategy = has-a
Edit: as for multiple inheritance, see Pontus Gagge's answer.