3 ms·

> JavaBean spec (with getters and setters) is actual standard. It's purely theoretical argument that you don't have to use them while in reality they are used a

by sgift 6y ago

> JavaBean spec (with getters and setters) is actual standard. It's purely theoretical argument that you don't have to use them while in reality they are used always and everywhere and any PR without them would be shot down immediately. Sounds like a strict "your company" problem. No one needs to use the JavaBeans spec. It's fully optional. > Yes, but I want that feedback during coding and not in CI/CD. Yeah, I can set it up in IDE, but that's more configuration, more things to break up, more team wide standards. Why not just use Kotlin? You make a very weak case here for Kotlin since you need a static analyzer anyway (e.g. Detekt). > I'm no Java hater, I code Java for most of the day professionally. But why pretend that it's perfect? It's 25 years old with unfixable mistakes built in and ripe for replacement. No one pretends Java is perfect. For many projects I like using Kotlin. But there's also substantial investment in Java and "I have to type a bit less" is usually not enough to justify using Kotlin.

The_Colonel 6y ago
> 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".
- pjmlp 6y ago
  Yeah, because Kotlin code full of !! isn't a thing either.

by sgift 6y ago

The_Colonel 6y ago

> 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".

pjmlp 6y ago
Yeah, because Kotlin code full of !! isn't a thing either.