> Sounds like a strict "your company" problem. No one needs to use the JavaBeans spec. It's fully optional. Your company - maybe I've been working in the wrong

> Sounds like a strict "your company" problem. No one needs to use the JavaBeans spec. It's fully optional. Your company - maybe I've been working in the wrong companies in the past 15 years, because Java's setters and getters have been used everywhere. Also look into some open source projects - how often do you see direct access to (non-final, non-package private) instance variables? Can't really recall a single case. For a good reason - exposing field access on a public interface violates encapsulation. > You make a very weak case here for Kotlin since you need a static analyzer anyway (e.g. Detekt). Of course static analyzer is necessary. That does not invalidate the claim that null safety guaranteed by a compiler is much faster/more effective. > "I have to type a bit less" is usually not enough to justify using Kotlin. Type less is a small price in typical large scale project. The big win is better readability since you don't have to scroll over tons of boilerplate or artificial abstractions caused by Java's rigidness. Besides that NPEs are still happening in production all over the world so something is obviously "not ideal".