No, you can have abstract classes without any abstract methods.
Monica Shiralkar wrote:. . . . Abstract classes are classes which have atleast one abstract method . . .
We should use abstract classes if we are expecting the classes implementing it to share many common methods or fields.
Campbell Ritchie wrote:Well done checking I wasn't sure on that point. I knew there were such things as private methods but had forgotten all other details.
My understanding is that default methods are sometimes just dummy implementations in order to hold a place for something useful in a class that implements it,
but also, that sometimes they are perfectly useful just as is.
The code in a default implementation can't access any writable data members directly,
because interfaces even now contain only public static final data members.
But they can call other member methods of the interface that are implemented by the class,
and have logical meaning even in the default.
So thinking of them as "just dummies" is too limiting, because sometimes they are perfectly good combinations
of other methods you will be implementing, and there is rarely going to be a good reason to @Override them to make good use of them.
There are numerous examples of both kinds
(dummies that are useless as coded, and perfectly good ones to leave as is and make use of)
in default methods added by Sun/Oracle in interfaces in Java 8 and later.
It is too limiting to just think of them as dummies that need to be overridden to be useful.
Campbell Ritchie wrote: Only blame Oracle for default methods; they weren't even thought of until Oracle took Sun over.
Campbell Ritchie wrote:but some are fully implemented.
Jesse Silverman wrote:Is what I said common consensus? I feel like there are a fair number of default methods that have been added to standard interfaces that are too useful to be ignored, and are just great as they are, and there is little to no reason to @Override them, just use them and enjoy them and profit from them.
The fact that Java does not have Multiple Inheritance makes me relatively reluctant to bite the bullet to go for an Abstract Class because we can casually implement as many interfaces as we need, but when it comes to a superclass, "There Can Be Only One".
Jesse Silverman wrote:Historically, if I thought I had a bunch of related only static utility methods, I would place them in a final class with no public constructor, which is the closest I could come to a "static class" in Java
He claims there is some big performance benefit, and talks about needlessly instantiating objects of a Class.
Monica Shiralkar wrote:I think, although the gap between interfaces and abstract classes have decreased after the introduction of default methods and static methods in the interface, the primary difference remains that Interfaces are contract to be followed by the classes that implement it and Abstract classes are like partially implemented and partially yet to be implemented by subclasses.
Campbell Ritchie wrote:I have never tried writing an abstract class with final methods.
Jesse Silverman wrote:My two overwhelming feelings were "Who made such a bloated interface that you feel you need to only implement part of it?" and "How are you sure that having these dummy stubs for parts you decide not to implement guarantees safe and effective operation?"
So, I haven't used Adapter Classes, and had the reservations mentioned above make me not in a rush to do so, but recall that they were described as having zero remaining abstract methods, yet it was recommended to still declare them abstract.