Pricing Engine: Default Conflicts, Function Order and a Mutable Record Key

Combo inherits two unrelated default String label() methods, one from Discount and one from Loyalty, and no class in the hierarchy provides an implementation. That is a compile-time error: "types Discount and Loyalty are incompatible; class Combo inherits unrelated defaults for label()".

The resolution rules, in order:

1. A concrete method declared in the class (or a superclass) wins over any interface default.
2. A default declared in a subinterface wins over one inherited from its superinterface.
3. Two unrelated defaults at the same level are a conflict and must be resolved by an explicit override.

class Combo implements Discount, Loyalty {
    public BigDecimal apply(BigDecimal p) { return p; }
    @Override public String label() {
        return Discount.super.label() + "+" + Loyalty.super.label();
    }
}

X.super.m() is only legal when X is a direct superinterface of the class. The private labelWith is completely legal: interfaces may declare private and private static methods (Java 9+), typically to share code between default and static methods. Such a method is not inherited, is invisible to implementors, cannot be abstract, and cannot be called as Combo.labelWith(...).

The signatures carry the constraint. For Function<T,R>:

• andThen(Function<? super R, ? extends V> after) requires the argument's input type to be a supertype of R.
• compose(Function<? super V, ? extends T> before) requires the argument's output type to be a subtype of T.

Here toCustomer is Function<Order,String>, so T = Order, R = String; len is Function<String,Integer>.

toCustomer.andThen(len): String is a supertype of String, and Integer is a valid V. Result: Function<Order,Integer>. Compiles.

toCustomer.compose(len): the compiler needs len to be a Function<? super V, ? extends Order>, i.e. it must produce an Order. It produces an Integer, and Integer is not an Order, so the types are incompatible - a compile error, not a runtime surprise.

Ordering: f.andThen(g) computes g(f(x)); f.compose(g) computes f(g(x)). So f.andThen(g) and g.compose(f) are equivalent, and f.compose(g) is the mirror image. Also remember a bare method reference has no type on its own: var f = Order::customerId; does not compile because there is no target functional interface to infer from.

Record key mutation. A record generates equals and hashCode from all its components. QuoteKey's hashCode therefore depends on List.hashCode, which depends on the list's contents. Appending a tag changes the key's hash. HashMap stores the entry in the bucket chosen at insertion time; a later get with an equal-but-differently-hashed key probes a different bucket, finds nothing, and returns null. A subsequent put also computes the new hash and inserts a second entry - the map genuinely holds both. The fix is to make the key immutable at construction, which a compact constructor does well (its body runs before the fields are assigned):

record QuoteKey(String customerId, List<String> tags) {
    QuoteKey {
        tags = List.copyOf(tags);   // defensive copy; NPE on null elements
    }
}

Retry helper. A lambda may capture only final or effectively final local variables; attempts++ reassigns the variable, so it is no longer effectively final and the capture is rejected. Use a single-element array (int[] attempts = {0}) or an AtomicInteger field, or restructure the retry as a plain loop. The array holder is not thread-safe, so for concurrent retries prefer AtomicInteger.