Covariant Return Types
A subclass can override a method and declare a more specific (narrower) return type than the parent method. This is covariant return type and does not break the Liskov Substitution Principle.
Covariant return = a restaurant menu that says 'returns Dessert,' but the subclass kitchen always serves Chocolate Cake specifically. You asked for dessert, you got something better -- still dessert, just more specific.
Covariant return types enable fluent builder patterns and clone() overrides that return the concrete type instead of Object. The overriding method must return a subtype of the overridden method's return type. Under the hood the compiler generates a synthetic bridge method with the original return type that delegates to the specific override, preserving binary compatibility with older call sites that expect the wider type.
Bridge methods are also generated for generic type erasure — when a class implements Comparable<MyClass>, the compiler generates a bridge compareTo(Object) that delegates to compareTo(MyClass). In bytecode there may therefore be two methods with the same name and different signatures (distinguished by return type, which is valid in bytecode but not in source). This is one of the few places where JVM bytecode is more expressive than Java source code.
Covariant return types let an overriding method return a subtype of the parent's declared return type. The compiler inserts synthetic bridge methods so older callers expecting the wider type still work. This is most visible in clone() overrides (returning the concrete class instead of Object) and builder patterns. It does not violate LSP because any code that expects the supertype still gets a valid instance of it.
Covariant return types are a source-level feature only — if you load bytecode compiled with an old JDK, bridge methods ensure binary compatibility, but mixing source and bytecode with mismatched expectations can cause verify errors.