Earlier quoted context omitted.
I don’t think properties add anything that getters/setters don’t already give you (other than slightly different syntax). I think the “right” way to replace the need for builders is to add support for named arguments.
> I don’t think properties add anything that getters/setters don’t already give you Except that you have to write them out by hand for every property you want in your code. Or generate them. > I think the “right” way to replace the need for builders is to add support for named arguments. Often you want to add validators to your setters. Just named arguments won't cut it.
Our analysis has determined that the vast majority of getters and setters are used in classes that are better replaced by records anyway (with all the benefits records bring that go far beyond conciseness, such as safe serialization and correct interaction with collections). The remaining cases are not numerous enough to pose a large enough problem that justifies an ad-hoc language construct, but could be further helped by a more general mechanism, such as concise method bodies (https://openjdk.org/jeps/8209434). The result is a smaller number of much more powerful features.
In other words, rather than making getters and setters easier to write, we simply get rid of the need for most of them altogether, which not only saves us a language feature, but also the downsides that setters and getters (or properties) have. We preferred tackling the problem at its source by asking what causes the need to write so many getters and setters in the first place (Java's lack of good data manipulation constructs) rather than treating the symptom (writing getters and setters is tedious).