On the same note, you could rebuke that by saying that, really, only those classes would need to be internal while keeping their attributes public. You can read about this argument in more detail here. There’s a decent argument against this, largely stating that most of those public artifacts should be something more akin to Kotlin’s internal modifier, but had to be public because Java’s visibility options aren’t the “right” set of options. First off, in JetBrains’ research of Java codebases, there is between 2.5 and 5 times more uses of public than private, and I agree with Kotlin’s decision that defaulting to public makes it all that much cleaner. I can see their point, but I don’t think it’s as likely to be to an issue as they seem to think. Those who are against it bring up the principle of hiding everything that you can get away with in order to preserve encapsulation, and that if it’s too easy, people will make things public that shouldn’t be. public by default (when no visibility modifier is used), and I would just like to pitch in on why I think JetBrains made the right decision on this one. Some people have spoken against Kotlin’s decision to make classes, methods, etc.

Kotlin visibility modifiers