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?

The PricingRule.apply objection doesn't survive: HotSpot classifies a call site by what it has actually observed at run time, not by how many classes exist anywhere in the codebase, and a call site production only ever calls with StandardPricingRule is monomorphic — the JIT devirtualizes it to essentially a direct call, exactly as fast as if the interface didn't exist, regardless of the test-only second implementation sitting unused elsewhere. The NotificationChannel.send objection, though, has real teeth: a single hot call site actually dispatching to twelve different concrete classes at run time is megamorphic (three or more implementations observed at one call site), and HotSpot gives up on the fast paths there, falling back to a genuine virtual-dispatch table lookup on every single call, with inlining stopped entirely. Same shape of interface, same reviewer objection, and the lesson's own mechanism gives opposite verdicts for the two — the number of implementations actually exercised at that specific call site is what decides it, not the interface itself.