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

[dmitriid]

> When it's ready.

So, I'm likely to be dead by then.

> You mean the approach that has consistently made Java so successful?

Why are you adding all these features from all these "non-successful languages" then?

Why is it that dealing with long chains of setter methods isn't "spending complexity budget" and is a "feature more bang than that" (whatever "that" is), but adding literally the same thing: better ways of working with collections is "no, we don't adopt features from less successful languages".

[pron]

> Why are you adding all these features from all these "non-successful languages" then?

The issue isn't the features themselves but the evolution strategy. Sure, we've been adopting most of the features added to Java since 1995 from ML (1972-3) and we're nearly done, but what we don't adopt is the approach of adding lots of features that each help a little. We like few features that help a lot.

> Why is it that dealing with long chains of setter methods isn't "spending complexity budget" and is a "feature more bang than that" (whatever "that" is), but adding literally the same thing: better ways of working with collections is "no, we don't adopt features from less successful languages".

We don't adopt an evolution strategy -- not features -- from less successful languages just because they're doing it. Java's strategy has been to innovate quickly on the VM (and we're innovating there more than anyone else, I think), and keep the language relatively conservative and relatively slow-moving. And it seems that more people like it this way. For the others, we make sure that the platform supports a choice of more feature-rich languages with good interop.

But the answer to your question is that we're trying to add as few features as we can (to leave room for growth in the futures, as requirements and fashions change again) and we believe that the features we do add help more than the ones we don't. Still, at the end of the day, there's hardly ever consensus among developers on anything. Whatever we do or don't do, some people won't like it. What's important to remember is that even if in some cases you don't agree with the language team's decisions, they are among the most experienced and successful language design teams in the history of software (I can say that because I'm not on the language team). They might make mistakes from time to time, but overall, they know what they're doing. In any event, the argument that millions of people prefer Pepsi to Coke is not the one that will convince Coke to change its flavour to that of Pepsi, because even more people prefer Coke.