[xpressvideoz]

I can understand the hate behind null-safe operators, but why properties? Why is bad to have an ability to "upgrade" a member variable into a property, without breaking any existing contracts? I really hate that I need to resort to using setters and getters in Java because those are bad for searchability.

[pron]

Properties are probably the worst feature on that list, and no experienced language designer would add them to Java. They make it easier to work with setters, while the goal is to reduce their usage altogether! Records achieve that much better. Unencapsulated component access is standardised on classes with good contracts (construction and deconstruction are duals for records) and will work well with patterns, all while avoiding unnecessary mutation for such classes (instead, we'll have "withers" or "reconstructors": https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...).

So we're killing two birds with one stone: making it easier to work with "simple data" while also reducing reliance on getters and setters. On the other hand, C# finds itself needing to add more and more capabilities to this feature, while Java dodged that bullet.

[dmitriid]

> instead, we'll have "withers" or "reconstructors

When?

> On the other hand, C# finds itself needing to add more and more capabilities to this feature, while Java dodged that bullet.

Java "dodged it" by never even having to fight. While C#'s "poor choices" are leading to a language with less and less boilerplate with almost each year, in Java we'll have to wait another 10 years before it delivers half of a half of the "withers" functionality that doesn't work with half of existing standard library code (the way arrays, lists and collections are three non-intersecting entities).

[kaba0]

But at the other hand, C# is heading in the direction of C++, where even after n years working with it, it can still surprise you/find yet another way of doing this and the rest.

Like, I would prefer not having 10+ initializers from C++ in a language.

[dmitriid]

But on the other hand you have object initializers directly in the language

In Java you have one of these:

- a hope that someone provided a useful static `.of` method

- a hope that someone provided the 15000 setter methods that you have to tediously invoke one by one

- a hope that someone provided a generator that created a builder that has 15000 setter methods that you have to tediously invoke one by one

Meanwhile in C#:

   new Object {
     x = ...,
     y = ...,
     z = ...
   }

for literally any object (provided properties are public of course).

And don't get me started on array vs list vs collections none of which are compatible with each other. And hundreds of other QoL improvements that are begging to be implemented, and are not.

[pron]

Easier construction for records will come to Java. As with most Java features, it will come once it's been carefully considered, and done in a way that gives the most bang for the buck (e.g. we do want easier object construction, but if we add a feature for that, we'll try to get more than just easier object construction out of it).

> And don't get me started on array vs list vs collections none of which are compatible with each other.

This is not true. Lists are collections, and while arrays are different, Arrays.asList() gives you a list view of arrays.

> And hundreds of other QoL improvements that are begging to be implemented, and are not.

First of all, just in the past five years we got local variable type inference (var), switch expressions, records (with much more to come), sealed classes, and basic pattern matching (with much more to come), and string templates are around the corner. All of those are significant QoL improvements.

Second, every feature comes at the expense of all others -- both because of opportunity cost and overall language complexity budget -- and the question is one of priorities. Not everyone has the same priorities.

Finally, because Java is expected to remain extremely popular for at least a couple more decades, we must be very careful about adding features. While other languages are trying desperately to gain many developers right away, we're looking ahead to ensure that we'll be attractive to developers in ten and twenty years from now, and so must spend the complexity budget carefully.

[dmitriid]

> Easier construction for records will come to Java.

Once again: when?

And why only records? Why does everything in java require someone to manually create an .of method, or create 15000 setter methods or generate those 15000 setter methods?

> This is not true. Lists are collections, and while arrays are different,

I remember running into an issue with the difference, but can't remember now. Quite possible it was an artefact of an early implementation.

> Arrays.asList() gives you a list view of arrays.

Yup. One of the hundreds papercuts that litter Java.

C#:

    var list = new List<string>()
    {
        "carrot",
        "fox",
        "explorer"
    };

    var array = new string[]{ "carrot", "fox", "explorer" };

    ... use whatever IEnumerable methods on both ...

Java:

Ahahaha. No. For lists use a static .of method and be glad that someone manually wrote that in the library. And be thankful that there's some shortcut to create an array. But for Lists? eff off, no shortcuts for you.

Oh you want convenience methods on arrays? Ahahaha, no. Use a separate helper to convert into a list first. (This is so bad that IDEA suggests some version .toList as the first method on I swear 90% of array/collection/list/stream operations).

Because, as someone said, "our goal isn't to adopt the strategy of less successful products, but to forge our own".

I'm really surprised records made it into the language with this approach to things.

Edit: Note: Ii use Java and C# interchangeably at my day job. Man is C# a nicer language with literally hundreds of QoL improvements that make you scream "why didn't Java adopt these?" I still reach for Java as I'm more comfortable with it and it has an unparalleled breadth of libraries.

But every time I need to write or implement and write another X.builder().setX.setY.setZ.build() instead of `new X { x=.., y=.., z=.. }` I want to claw my eyes out.

[kaba0]

It was more of an example on C++, and I agree that many features of C# are great QoL improvements! But at the same time, I do feel that sometimes the language committee would be better not implement a feature just yet and wait for a better abstraction that makes 2-3 features possible at the same time. That way the cognitive load of the language would decrease by a lot.

And yeah, C# feels to me to be on the way to being way too feature-packed, which can be a detriment in the extreme.

[xpressvideoz]

Thanks for the thorough explanation. Now I understand where Java is heading for. The aesthetics regarding withers concerns me a bit though, because I don't like prepending anything to the name of an acceessor (a transformer, in this case?), which was why I liked the idea of properties in the first place.

I hope both Java and Kotlin can converge into a common coding style. As you said regarding C#, Kotlin's emphasis on properties makes it easier to use getters and setters and thus may hinder getting rid of them in the Java ecosystem. I'm not sure if I should support Kotlin's success at this point.