Code10x
Structural patternssenior8+ years

Given `Proxy.newProxyInstance(loader, new Class<?>[]{ PaymentGateway.class, AutoCloseable.class }, handler)`, describe precisely what gets built, when, and why the exact same mechanism means this call would fail outright if `PaymentGateway` were a concrete class instead of an interface — versus why a `final` class specifically breaks Spring's *other* proxying strategy in a completely different way.

Proxy.newProxyInstance doesn't fake anything or intercept calls through reflection tricks at call time — it generates an actual, real .class at run time that genuinely implements every interface it was handed (PaymentGateway and AutoCloseable both, here), with every method of both interfaces implemented to do exactly one thing: package up which method was called and with what arguments, and hand that off to the InvocationHandler. That generated class is cached per distinct interface set, so the generation cost is paid once, not on every proxy creation. It would fail outright for a concrete class because the mechanism can only generate a class that implements interfaces — Java has no multiple inheritance of implementation, so there's no way to generate a class that both implements PaymentGateway-as-a-class's behaviour and is a distinct object; Proxy is structurally an interface-only tool. final breaks the other mechanism (a generated subclass, via ByteBuddy/historically CGLIB) for a completely different, unrelated reason: that strategy works by generating a class that extends the target and overrides its methods, and Java forbids extending a final class at the language level — a different limitation, hit by a different proxying strategy, for a different structural reason.

The lesson behind it →
PreviousA cache is built as `Map<Order, InvoiceDraft> pendingInvoices = new HashMap<>();`, keyed by the `Order` aggregate itself, with `equals`/`hashCode` overridden to include `status` because "two orders are only really the same if they're in the same state." Orders go into the cache while `OPEN`, and `pendingInvoices.get(order)` starts returning `null` for orders that are definitely still in the map. Walk through exactly what happens, bucket by bucket.Next A codebase has two call sites: `PricingRule.apply(order)` where the concrete implementation is always `StandardPricingRule` in production (a second implementation exists only in tests), and `NotificationChannel.send(msg)` where twelve concrete channel classes are registered and dispatched from one hot loop. A reviewer objects to both interfaces on performance grounds. Which objection, if either, survives contact with how HotSpot actually compiles these call sites?
More on Structural patterns
`@Transactional void placeOrder(Order o) { save(o); notify(o); }` calls `private void notify(Order o) { ... }` on the same class, and `notify` is also annotated `@Transactional(propagation = REQUIRES_NEW)` — the intent being "notify commits in its own transaction, independent of placeOrder's." It doesn't. Why not, precisely, and would making `notify` public fix it?