[twh270]

Much of the verbosity came from the false presumption that every field in every class needs a public getter and setter. (I cannot express in words how terrible this is.) Some can come from the framework, mostly poorly-designed ones.

I think Java 11 and higher are reasonably terse/expressive without being overly dense.

[DaiPlusPlus]

Remind me, why doesn’t Java have object-properties yet?

So far the only reason I’ve concluded is Java’s language designers’ egos were so damaged by C#, Swift, Kotlin, TypeScript, etc that after dogmatically denying the developer-productivity benefits of properties for the past 20 years that to concede now would mark the end of Java as a language entirely.

...I kid, but seriously I haven’t heard any compelling argument from the Java camp yet for refusing to add this feature. Object-properties are easily the lowest-hanging-fruit with the biggest productivity-gains.

Heck, even some of the most popular C++ compilers support object-properties as proprietary extensions.

[zmmmmm]

It's so crazy - with all the huge and radical features they've added this would surely have been so simple by comparison and yet added more value than about 80% of the things they've done. It's about half the reason I still use Groovy now since Java has solved most of the rest over time. But I just cannot go back to writing getters and setters!

[kaba0]

I believe the Java lang team simply dislikes the Java Beans convention, and if they see a better future, they rather not maintain properties forever.

I think the current future view is Withers ( https://github.com/openjdk/amber-docs/blob/master/eg-drafts/... ).

[doctor_eval]

Couldn’t agree more, the madness of idiomatically adding setters and getters to every field was something I ended up putting an end to in my last gig, and my life improved immeasurably as a result.

[pgwhalen]

I think I'm going to convince my team to get to 16 (with records) before I can convince them to stop adding getters and setters everywhere, but just out of curiosity... how did you manage to make this happen?

[doctor_eval]

Well - I was the boss :) so that helped. But I’d also taken over a fairly unhappy and unproductive team that was ready to try new stuff. I’d been out of the game for a few years and had some fresh perspectives too.

So I did some small standalone projects and demonstrated how much easier life was with this and other (more significant) changes. For example, we had loads of operational problems with dependency injection - the usual cognitive and debugging issues - so I threw all of that out too, along with the frameworks that implemented them. Things started booting in a few seconds instead of minutes and I’d say the lack of setters/getters was mostly done because I built trust in my team that I was making their lives better so they just followed me.

Probably not the answer you were looking for but there was friction from the devs and in the end I just showed them how much nicer life could be...

[The_rationalist]

Kotlin property access solves this. You access to the property but behind the hood it will call the getter/setter if it exists.