Abstract Class vs Interface
An abstract class can have state, constructors, and both abstract and concrete methods. An interface defines a contract (abstract methods) and since Java 8, can have default and static methods. A class can implement multiple interfaces but extend only one class.
Abstract class = a partially built house (has walls, plumbing, rooms). Interface = a building code (rules to follow, no bricks). You can follow many codes but only inherit one house.
Post-Java 8/9 interfaces can have: default methods (concrete, inherited by implementors), static methods (not inherited), and private methods (Java 9, for sharing code between defaults). Use an abstract class when you need to share state or provide a common constructor; use an interface when you're defining a capability/role that multiple unrelated classes might fulfill. Functional interfaces (one abstract method) power lambda expressions. Interface default methods enable backward-compatible API evolution without breaking existing implementors.
Diamond problem with default methods: if two interfaces provide a default method with the same signature and a class implements both, the compiler forces explicit override resolution via InterfaceA.super.method(). Abstract classes have access to protected constructors and can enforce initialization contracts (Template Method pattern). Interfaces cannot have instance state (only public static final constants) — attempting to model state via interface defaults is an anti-pattern. Java 17+ sealed interfaces (combined with sealed classes) enable exhaustive pattern matching in switch expressions.
Abstract classes allow shared state, constructors, and access modifiers on members — use them for 'is-a' relationships with shared implementation. Interfaces define contracts and, since Java 8, can provide default implementations for backward compatibility. The key practical difference: a class can implement many interfaces but extend only one abstract class. For new API design, prefer interfaces (gives implementors flexibility); use abstract classes when you need to enforce initialization or share significant implementation.
Adding a default method to a widely-used interface is both source- and binary-compatible, but can be behaviorally incompatible: if a class already has a method with the same signature, the class method wins by JLS resolution rules, so the default method is silently ignored — the semantics may diverge from what the interface author intended.