Java makes methods overridable by default, while C++, C# and Kotlin require the base author to opt in with virtual or open. Argue both positions: what does opt-in overridability buy, and what does it cost consumers of a library who need an extension point the author did not provide?

## The decision Every class-based language must choose a default for whether a method participates in dynamic dispatch. It is one flag in a specification and it reshapes how libraries are written, tested and evolved. ## The case for opt-in, language by language **C++** chose non-virtual by default for cost. A class with no virtual functions has no vtable pointer, fits in the size its members imply, and its calls inline. That is the zero-overhead principle: you do not pay for dispatch you did not ask for. The famous consequence is the base destructor -- delete a derived object through a base pointer whose destructor is not virtual and the behaviour is undefined -- which is a direct tax on making the safe thing opt-in. C++11 added `override` and `final` because the silent-failure modes of the default were costing more than they saved. **C#** kept non-virtual by default and went further, requiring `override` at the override site and `new` to declare a deliberately shadowing member, plus `sealed override` to stop further overriding partway down. Nothing is accidental in either direction. **Kotlin** made classes final too, not just members. The stated rationale is Effective Java's Item 19: design and document for inheritance, or prohibit it. An unopened method has no subclass contract, so its behaviour, its self-calls and even its existence remain the author's to change. **Swift** is subtler: methods declared in a class body are dynamically dispatched, but methods added in an *extension* are dispatched statically and cannot be overridden. The same declaration in two syntactic positions gets different dispatch, which is opt-in virtuality expressed through file layout rather than a keyword. ## The case against Sealing shifts risk from the author to the consumer, and the consumer usually has fewer options. - **Testing.** Mocking frameworks that work by subclassing cannot intercept a non-virtual member. This is the practical reason C# codebases extract an interface for almost every collaborator: the interface exists to restore a seam that the language default removed. Kotlin teams hit it the same way and reach for `mockk`'s inline instrumentation or open up types under test. - **Frameworks.** Spring generates proxies by subclassing, so Kotlin classes are unusable as beans by default. The response was the `all-open` compiler plugin, which opens annotated classes automatically. When an ecosystem ships a plugin whose entire purpose is to reverse a language default, the default is contested, not settled. - **Adaptation.** If a library author did not open a method and you need to change its behaviour, your remaining options are wrapping the whole type (only works if it implements an interface), forking, or bytecode manipulation. Java's default at least leaves the door unlocked; whether that door should have been unlocked is exactly the argument. ## Java's rebuttal The cost argument, which motivated C++, is weak on a JIT runtime. The compiler performs class hierarchy analysis: if only one implementation of a method is loaded, the call is devirtualized and inlined, guarded by a check that deoptimizes if a second implementation appears. Polymorphic call sites get inline caches. So the throughput difference between virtual-by-default and final-by-default is small in practice, and `final` as a performance hint is largely folklore. What remains is the *contract* argument, and there Java is genuinely exposed. Any public non-final method is an extension point whether or not you designed one, which means its self-call pattern is observable, its behaviour is depended upon, and a constructor-time call to it can reach a subclass override. Java's `sealed` classes and interfaces exist to give authors control over hierarchy shape, and record and enum types are implicitly final, which shows the language moving toward closure where it can. ## The dynamic end of the spectrum Python and Ruby have no sealing at all: everything is overridable and, beyond that, replaceable at runtime. Ruby's `prepend` inserts a module ahead of a class, so a third party can wrap any method without subclassing. The defence is convention -- Python's double-underscore name mangling, a leading underscore signalling privacy -- and the culture accepts that consumers can and will reach in. Total flexibility, zero enforceable contract. ## Making the call For a library published to strangers, opt-in is the defensible default: every open method is a promise you must keep across versions, and closed methods are your only freedom to evolve. For application code inside one repository -- where you can change every caller in the same change -- the argument mostly evaporates, and the cost of ceremony is real. Two practices soften the tradeoff regardless of default: the non-virtual interface idiom (a public non-overridable method that calls a protected overridable hook, so the author controls the sequencing and the subclass supplies only the variable step), and separating the *client* interface from the *specialization* interface so the extension points are explicitly named. Both let you be closed by default without being unextendable.