What I meant was that we don't adopt a feature just because some other language has it, let alone from languages that don't have the same philosophy as we do of trying to have as few features as we can get away with. Records are overall more valuable than properties (due to various reasons, from serialization to interaction with collections). But once you have records with "withers" the question becomes how valuable is it to also have properties. It doesn't seem like it would be helpful enough to overcome the drawbacks.
BTW, C# didn't add properties as a "lesson." Properties in C# and JavaBeans have the same pedigree: RAD UI composer tools of the 90s [1]. They came to C# by way of VB. So really, Java would be adopting a VB solution, and there needs to be a good reason for that.
A year ago I already said all the good reasons. There are many reasons why things like Lombock exist. There are reasons why people loathe writing interminable chains of builder methods.
But sure. None of these are good reasons because something something Visual Basic.
What Java will inevitably end up with is a yet another half-assed approach that only exists for a small part of the language and is not applicable to the rest of it.
> BTW, C# didn't add properties as a "lesson."
That's not what I wrote. This is literally from your link: "Digression: learning from C#"
And look. Right below it, emphasis mine
--- start quote ---
The C# approach was sensible for them because they could build on features they already had (default parameters, properties)
--- end quote ---
And look. "Extrapolating from records" section basically says: Java has nothing, and will need to rebuild everything from scratch for this not to be a half-assed solution. Oh well.
> The C# approach was sensible for them because they could build on features they already had (default parameters, properties)
You've misunderstood. Once you have properties it makes sense to go a certain way. If you don't, it makes more sense to add records and not properties.
Now you don't have to agree with the Java team's decisions. Programmers rarely agree on much. But I think you should at least appreciate the irony that if we had added properties, I would be responding right now to another equally annoyed person complaining that we're not learning the lessons of Go and Zig and Rust, which have refused to add properties, and couldn't we see what an obviously stupid idea it was.
> But I think you should at least appreciate the irony that if we had added properties, I would be responding right now to another equally annoyed person complaining that we're not learning the lessons of Go and Zig and Rust
Most likely not.
Meanwhile C# could build on the strength of what they have in the language. And Java, and I cannot repeat it enough times, will have a half-assed solution applicable only to a small part of the language while keeping the inanity of manual `.of` methods, manual interminable chains of builder methods, and other half-assed solutions everywhere else.
While denigrating other languages and their decisions.
Even the link you provided clearly states this: "And, everything we can do with records but not with classes increases a gap where users might feel they have to make a hard choice; it's time to start charting the path of generalizing the record "goodies" so that suitable classes can join in the fun."
Again: while others have built on the languages features they have, and they are immediately propagated through the language with little to no additional effort, "Java does not adopt strategies from less successful products", and "keep the language conservative". And yet here we are, "learning from C#" and struggling how to figure out a simple (for some definition of simple) addition so that it works with the rest of the language that has languished in the "conservative" land for too long.
Edit.
I also wonder how many of the things that are currently placeholders will be required and will surpass anything C# and other "lesser languages" have come up with: factory, __byname, __deconstructor etc.
Out of curiosity: given that virtually all features in Java were adopted from other languages (almost always less popular ones) so there clearly is no aversion to that, and given the level of experience and success of the Java team, not to mention their clear interest in Java's success -- i.e. they have both the motivation and ability to do what's best for Java -- what possible reason do you think they have to do something that to you seems so obviously wrong?
Moreover, why do you conclude that propertied are the only right choice, seeing that Java is far from being the only language without them? You should, at best, conclude that some language designers like them and some don't.
> Even the link you provided clearly states this: ...
That refers to pattern matching and withers. Records don't have properties either.
> what possible reason do you think they have to do something that to you seems so obviously wrong?
We are all human. That's the main reason.
That's why instead of a unified way of creating collections (and lists and arrays) you need to manually write out `.of` methods and hope that the authors of the library that provides collections (whether built-in or external) provided those methods.
That's why instead of a unified way of creating objects you need tedious manual builder patterns, manual getter/setter boilerplate or code generation.
That's why <hundreds of low-hanging fruit for DX>
That's why the proposal couldn't re-use existing language features (like C# did in the first approach, and as is acknowledged in the proposal).
So you will end up with what is essentially an object initialisation syntax... but only available in this one construct. And will then spend another five years trying to bring it to the rest of the language, again in a very limited capacity. Because something something "conservative language" and "less successful languages".
> Moreover, why do you conclude that propertied are the only right choice
Surely you see that those who have come to the opposite conclusion can be equally convinced that it is you who has made what seems to them an obvious mistake for the very same reason.
If we're honest, we should acknowledge that since there is no actual empirical evidence showing one way is superior to the other here, and since experts have come down on both sides, then there's probably a strong aesthetic component, in which case it makes for a language to remain true to the aesthetic principles that have proven successful for that particular language.
> Because something something "conservative language" and "less successful languages".
You keep missing the point about the "less successful languages." All of Java's features come from less successful languages. I was merely saying that the fact that some languages have a feature is not a reason to adopt it. It's just that if that language was doing better than Java, then there would at least be some social merit to the argument "you should do it because they do", but otherwise it's not an argument at all because other languages don't do it, so there's simply no guidance there.
"You should do it because some people really want it" is similarly unhelpful because whatever "it" is, there's usually a similar number of people who want the exact opposite, and just as insistently. That is why different languages end up making different choices.
Neither of these is an argument at all. All they mean is that other options exist, but they don't help choosing among them. That some languages do one thing and others do another, that some programmers want one thing and others want the opposite is a given.
Now, from my personal perspective, the uniformity and power you want are better served by ADTs than by properties, it's just that you haven't appreciated the extent of the power that ADTs bring when used as intended (it's not really a distinctly separate construct), nor appreciated the significant downsides that properties bring along with their benefits, that are quite measly in comparison to ADTs. Then again, there clearly is no consensus on this, just as there is no consensus on just about anything, and whatever choice is made, some will be unhappy.
Some other things you want may well end up being features in Java, it's just that we believe other things take priority. As for those that won't, our desire to minimise language features if we can help it may be a purely aesthetic choice, but it's one that's worked well for us (just as the opposite may work well for other languages). Without any good evidence that we should abandon it, the fact that some languages don't share our aesthetics is surely not a sufficient reason to abandon it.
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.
> Except that you have to write them out by hand for every property you want in your code. Or generate them.
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).
Why not have all other lessons from C# like `{get; set;}` and object initialisation (among other things) syntax is beyond me.
(Well, "we don't adopt strategies [whatever that means] from less successful languages" is a reason I guess https://news.ycombinator.com/item?id=28985688)