New language features since Java 8 to 17

C# 9 has more features in the release (one year after the release of C# 8) than java had in the past five years.

Whatever "seems" to you, it clearly isn't true.

> > It won't, not for another ten years.

> You're very wrong about that. Remember that only five years ago, Java didn't have var, didn't have switch expressions, didn't have text blocks, didn't have records, didn't have sealed classes, and didn't have pattern matching.

Me: Java is moving too slowly

You: no-no. Some people even think we're moving too fast. Here, we have five features in five years. Some of those features should've been there 20 years ago.

> it's that we don't copy their evolution strategy.

It's a great delusion. Java's development is abysmally slow. It has nothing to do with "quick-feature-loving minority" as you so condescendingly put.

Java moves in fits and starts, taking 5-10 years to add some features that often don't fit with either the rest of the language, or with half of the standard library. Almost literally everything takes near a magnitude more boilerplate to write and develop than it should. And when it's not, it's only available to some parts of the lang, and not to the other.

But when you express concern about this? Oh, then you're a "quick-feature-loving minority", and not a developer earning their living with Java and hoping for any meaningful improvement to it.

Oh, I'm sorry. I'm not smart enough to understand why a possible solution to tolstoyesque method chaining calls that will maybe come to Java in 10 years is "evolution of the language", but literally the same solution to collections (and unifying lists and arrays) is "a quick feature from less successful languages, and we don't adopt evolution strategies from those".

As I don't understand a hundred other things that can elevate Java-the-language from mediocre to great.

and ugly and verbose and all the things you mentions are bolted on after that fact or not even apart of the core programming language. which hurts your agreement of its being "elegant" or "designed well"

Not even close. They're adding small features to the language, while Java adds huge features to the runtime. .NET is 10-15 years behind Java on the runtime. Roughly speaking, Java's philosophy (going back to Gosling) has been to innovate on the runtime and keep the language conservative, while .NET's has been to add a lot of features to the language and keep the runtime relatively crude. There is no indication that changing our strategy would be a wise move.

> Some people even think we're moving too fast. Here, we have five features in five years.

Not some; most. Most people prefer fewer than five features in five years, even though many prefer more. I really wish we could make both you and the others happy, but I don't see how we can do that other than what we're already doing: have Java be the popular mainstream language, and support other languages on the platform for those who prefer something else.

> Some of those features should've been there 20 years ago.

Should have been there so that what? Or at the expense of what? Our goal is to build a successful language used by millions, not to push the envelope in programming language design (although we are pushing the envelope in runtime design). We introduce features when we think mainstream programmers could use them in the best way, and we add them slowly enough so that we're not overtaken by fashion and we have room to grow for decades. You may not like it, it's okay, and it's even perfectly reasonable. But this has worked really, really well.

> It's a great delusion.

Fine. Maybe you have more access to market data than we do. Fact of the matter is, no other language is doing any better, and Java has fewer serious competitors today than it did in the last 15 years.

> But when you express concern about this?

I am not dismissing your concerns. I am merely explaining that we have about ten million other developers we cater to aside from you, and they don't all share your opinions. Your views are far from unique, and we are well aware that many people want the language to evolve faster -- and that's perfectly legitimate although I personally don't think it's a good idea for such a popular language -- but even more don't.

Ah yes. Using a single common way to initalize things and unifying arrays and lists (so that you don't need helper modules, and you don't have to rely on the kindness of libs to provide .of methods) is "fashion" (as are many other things).

But "yeah, we will maybe some day 10-20 years from now provide a way to build records, and only records, in a way that doesn't require hundreds of lines of boilerplate", that's long-term strategic planning and evolution.

Well, we're talking past each other. I'm well aware that any change in a language the scale of Java is a daunting task. But the condescending tone that dismisses something as "features for the quick-feature-mided fashion crowd" clearly shows that it's not these concerns that drive these decisions, but purely subjective outlook on things.

I think that being honest about our strategy that dates back to Java's inception -- an innovative runtime and a conservative, slow-changing language -- that has worked well for us and so we're sticking to is more respectful than giving you some non-committal marketing response. I think you should also be respectful and understand that the Java language team is one of the most successful and experienced language design teams in the world and know what they're doing, even when people might disagree with some decisions. Even experts disagree, and people have different tastes (I find C# and contemporary Kotlin positively garish, while I think Clojure and Zig are elegant and beautiful).

And the language features Java does intend to adopt will come quickly, just as the smallish-medium ones over the last few years have. I believe lambdas were the only language feature that took more than a couple of years to deliver. Once the language team decide they want a feature, they deliver quite quickly. The features that take a long time are usually changes to the runtime (what I mostly work on), not just the language.