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.

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.

What is equivalent to a package-private interface for encapsulating internal functionality of a package?

I am attempting to encapsulate all of the internal functionality of a service package. Most of my classes and methods are package-private. I have some internal interfaces that I don't want to expose outside of the package. I can make the interface itself package-private however all of the methods are still public (the default scope for interface methods).
What are my options for eliminating the public method signatures from my internal implementations in this package?
I am using interfaces so that I can easily switch out implementations using spring.
Some Things to Consider: Development tools that use source code analysis will report the interface methods as public API methods. For example a UML generator would generate a misleading UML diagram that incorrectly shows this as a public method.

One possible solution, as already #Bart has pointed out, is to use abstract classes instead of interfaces. A possible problem connected with this concept is a single-inheritance issue.
Another solution could be a separation of the "private" interfaces in a different package which doesn't need to be published together with your service package thought this method can quite ruin semantics of the interfaces, specially if one logical interface would have "private" and "public" part.
Last work around which has come to mind is to utilize some patter e.g. Double dispatch or Visitor could be useful.

why does Java does not promote a separation between class definitions and class implementations [duplicate]

This question already has an answer here:
Closed 11 years ago.
Possible Duplicate:
C++ promotes a separation between class definitions and class implementations but not JAVA
I want to know why does JAVA does not do like in C++ and promotes the separation between class definitions and class implementations. Are there any advantages with that way of working or proceding for a mather of code reuse of extensibility?
Moved to https://softwareengineering.stackexchange.com/questions/118574/c-promotes-a-separation-between-class-definitions-and-class-implementations-bu

Java does offer the ability to separate type definitions from their implementations. Use an interface to define the type and a class implementing that interface for the implementation.

Java supports separate definition of interfaces and classes.

You can have the same kind of separation between definition and implementation in Java. We do it all the time in our development work through Interface Driven Design. We design the entire system as a set of interfaces that represent behavior and functionality in the system. Once the interfaces are defined, we create implementing classes that realize the behavior defined by the interfaces.
This gives us the ability to refer to our components by there interfaces and the flexibility to replace particular implementations without having to modify the references throughout the code base.
The one caveat about such a design method is the need to do dependency injection to maintain the separation between types. The dependency injection can be done either manually, or, as most people do it, using a DI framework such as the one included in Spring.

Java's creators encourage coding by interface (known as design by contract). An interface is somehow similar to an abstract class in C++, with the following enforcement : all declared methods are abstract and public, no class variables are allowed, constants must are public.

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.