[pron]

> More modern languages, like C# and Kotlin, use properties for this instead which can do that automatically.

It's not about being "modern" but about differing opinions on language design. The subject of adding properties to Java has come up numerous times over the past twenty years, and even though we're adding quite a few new features -- most recently, algebraic data types -- properties are not added because we just don't want them. Their "bang for the buck" is low, their potential for abuse is high, and adding them to an established language is even less appealing, as it creates a clear old/new code divide. Most of all, it's unclear whether the style of programming that relies on mutating individual fields is something that should be encouraged in the first place.

Another controversial feature that C# and Kotlin have but we don't want to add to Java is extension methods. It's perfectly reasonable for different languages to reach different conclusions regarding certain features, with some biased more toward happily adding features while others are more conservative, and it's perfectly reasonable for different programmers to have different preferences. The important thing is that features are carefully considered by language designers before being added, and that the language's "feel", philosophy and context is taken into account.

[kbenson]

> Their "bang for the buck" is low, their potential for abuse is high, and adding them to an established language is even less appealing, as it creates a clear old/new code divide.

I'm not a Java programmer, but I agree wholeheartedly WRT addin a feature like this to an existing language with wide use. There's a world of difference between adding a feature that's obviously different than what came before and looks obviously different than adding one that changes functionality but looks identical to prior usage. If people learn a language and during that it's made clear that assignments can have arbitrary side effects, they'll expect that. If they learned the language and that wasn't possible, introducing it at some point is going to mean a lot of programmers have ways of thinking about how control flow works and what happens when you make assignments that is subtly (or greatly) wrong, but only sometimes.

As a programmers, what that can feel like is that the language is actively sabotaging your understanding of it. It's not fun.

[ivan_gammel]

I like your way of politely explaining „thanks, but no, thanks“ and totally agree with it. Properties are usually useful in cases where small immutable record would also be fine. With general purpose property interface of a complex business model it is too easy to make mistakes even for an experienced engineer. Validation or computations in constructor or business method would be more natural and flexible.

[jasonboyd]

I rather like extension methods. I was not aware there was any controversy around them.

Edit

This wikipedia article suggests Java has extension methods, or maybe something functionally equivalent (I'm not a Java programmer): https://en.m.wikipedia.org/wiki/Extension_method

[pron]

> I was not aware there was any controversy around them.

Not controversy so much as that they're not close enough to being universally liked.

> This wikipedia article suggests Java has extension methods, or maybe something functionally equivalent

That uses a compiler plugin that changes the language quite considerably.