However, we know that most classes should be closed ( Effective Java Item 17: Design and document for inheritance or else prohibit it). Kotlin tries to encourage good practiceīroadly, Kotlin does an excellent job of correcting flaws in Java that make it easier to write bad code than good.Ī similar analysis of Java code would likely have revealed that most classes are not final. While the motivation is definitely to be applauded, the reasoning misses the mark it conflates brevity with cleanliness and ends up sweeping a major problem under the rug. That spirit clearly motivates the above argument. Kotlin is a deeply pragmatic language, designed with great care and feet planted firmly on the ground. Why the reasoning for public-by-default is flawed So we decided to use it by default to keep our code clean. In our experience explicit public breaks the flow of many DSLs and very often - of primary constructors. This means that we’d make people write public all over the place to implement their designs, that would make Kotlin a lot more ceremonial, and we’d lose some of the precious ground won from Java in terms of brevity. In real Java code bases (where public/private decisions are taken explicitly), public occurs a lot more often than private (2.5 to 5 times more often in the code bases that we examined, including Kotlin compiler and IntelliJ IDEA). The blog post announcing M13 included this reasoning for the change:

The default visibility was changed from internal to public in M13, on pragmatic grounds. Therefore, making internal the default can save substantial work as code bases evolve. That is, changing an internal class or member to public requires no effort since there are no external callers – doing the reverse after external callers have been written could have large ripple effects. If a class or member initially has the wrong visibility, it’s much easier to increase visibility than reduce it. How to Design a Good API and Why it Matters (PDF), slides 14 and 16 (note that public classes and members constitute an API).

Effective Java, Item 13: Minimize the accessibility of classes and members.

I can’t say it better than Josh Bloch, and I doubt this is controversial here. Why the default should be internal Visibility should be minimized

Internal modifier kotlin