[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.

[qw]

I know it's probably to late to add any value to the discussion, but you can write this in Java;

    var list = List.of("carrot", "fox", "explorer")

You are right about the builder, but most projects I have worked with use Lombok and the @Builder annotation to generate the builder automatically. I agree that a native syntax for this would be better.

[pron]

> Once again: when?

When it's ready. Again, because of Java's position, we aim for features that will work well for decades rather than those that will grab some more users now. I know this is hard for some to understand, but the main complaint we're getting is that Java is getting too many features too quickly, not the other way around. The people who like lots of features are a minority; a large one, but still a minority. Whether we add a feature or don't add it, some people will be disappointed. It's impossible to please everyone, so we try to please the majority.

> Ahahaha.

    var list = List.of(
        "carrot",
        "fox",
        "explorer");

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

This is not where we think the language's complexity budget is best spent. When we do add a feature to the language, we want it to have much more bang than that. Those who like lots of features don't like that but, again, they're the minority. I cannot stress enough how much people hate language features. Language features don't have Javadoc, and people have to learn them. If they have to go and learn a new feature, they expect it to be worth it.

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

You mean the approach that has consistently made Java so successful? We try to add as few features to the language as we can afford to, which means that we make the features we do add extra powerful. This gives us room to add some of the features people will be asking for in ten years, rather than waste all of the complexity budget now.

> "why didn't Java adopt these?"

Because Java's strategy is different, and it's working better.

> 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.

With that I completely agree, which is why we'll address that.

[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.