I’m a huge fan of C# and how Microsoft has been improving .NET recently but as a C# fan I think you’re being a little unfair to Java. It has a slightly different perspective on language evolution than C#, in that they try to keep the language core smaller. I was overwhelmed by syntax when I first started programming C#, from all the different kinds of parameters (optional, named, ref, out, in) to all the different kinds of properties, to the actual difference between properties and fields. To this day I think it’s silly that certain tools and style guides will suggest you replace public fields with public auto-properties, when there is no difference in encapsulation in practice. In this sense C# is closer to the culture of C++, where the bar for adding features is quite low.

Java just moves a lot slower, and has a different philosophy for adding features, and the core team seems averse to introducing new forms. An example I ran into the other day is applying first-class functions in Java: in C#, this looks like

  lambda(arg1, arg2)

while in Java it’s

  lambda.apply(arg1, arg2)

This is definitely more verbose and arguably uglier, but it hews closer to the object-oriented style because it’s visibly falling a method on an object. Of course this is happening in C# as well, but it’s hidden by syntactic sugar.

> This is definitely more verbose and arguably uglier, but it hews closer to the object-oriented style because it’s visibly falling a method on an object. Of course this is happening in C# as well, but it’s hidden by syntactic sugar.

It's hard to appreciate how addictive the sugar is if you never had it.

Frankly, language level auto properties -alone- would get rid of 25-33% of the pain I feel writing Java.

Of course, there is always Scala on the JVM Side; which gives you all sorts of sugar, but in some ways -too much-.

I think from an object-oriented design perspective that it's quite easy to overuse public field members and that a lot of getters and setters is generally a code smell. Nonetheless, properties are a very sharp tool and having them in the toolkit is wonderful.

I've never used Scala but it seems to go much further in the syntactic sugar and semantic complexity direction, more akin to F# than C# (though with less elegant syntax, to my eye).

There have been many iterations of 'Java except it doesn't suck', but which all were extremely similar to Java - Xtend, Groovy, etc. So when Scala came onto the scene, even though it was a serious functional language and encouraged a very different style of programming than Java, it was seized on as a 'Java except it doesn't suck' language because it was much more different than previous ones and so felt more like a fresh start. The sentiment hasn't died yet, although Kotlin should at this point be treated as the official 'Java except it doesn't suck' language, since it's designed directly for it, is different enough, and has mainstream adoption.

Lombok fixes most of the getter/setter issues. It is also supported in IntelliJ

However bad the Java situation is, Lombok as a solution is worse. It uses unsupported and undocumented APIs of the compiler, it autogenerates code that is in some cases flat wrong (like the infamous enum @ToString), and it does this through a mechanism of the language specifically designed for pure metadata - code that compiles with annotations should not cease compiling without them. And, because of the way it does what it does, IDEs must have explicit Lombok support built into them. It is, effectively, a different language that's a superset of Java; at that point, you may as well actually use a superset of Java like Groovy, and then you don't have tools prone to breaking.

I’m not a huge fan of libraries that use attributes as a hook for code generation in C# either, though thankfully there’s less need for something like Lombok.

I am not saying Java's model of never adding important things is better or worse. I might now say it is worse, but that wasn't the point I was making - I was simply responding to a comment saying Java has added important things, when it hasn't.

Also, auto-properties are binary compatible with computed properties, whereas public fields aren't, and you can use 'ref' on a public field whereas you can't make a ref to a property.

I realize there are differences between fields and auto-props when using certain other features, but from a design perspective, these are identical within an assembly:

  public int Foo { get; set; }
  public int Bar;

Java has absolutely made important improvements, and there are even more impressive ones on the horizon. In particular you should look at Project Loom, which is Java’s answer to async/await. It’s not finished yet because the design is much more general and novel, and it avoids the “function color” problem that async/await has. It’s inspired in part by Erlang/BEAM’s green threading system.

You might also look at the JDK flight recorder, which is an amazing feature that .NET doesn't have. The Java perspective is adding complexity to the runtime fiest instead of the language.

Having primitive int as opposed just using Integer in the first place was the original sin of Java. I am perfectly fine with not proliferating that further, List<Integer> with autoboxing pretty much allows you to use primitives when working with List<Integer> and the workflow is seamless. await would definitely be nice, it's a shame Java doesn't have it. It's a bit weird to call the features they have added as "stolen from C#", these features have existed in other languages for decades- ML had type inference in the 70s, lambdas have been there since the 60s. They are not "C# features".

There have been many useful improvements between Java 8 (the lambda release) and Java 11, I haven't looked beyond 11 as I haven't worked in Java in over a year and that was the last version I wrote code with. I don't even consider var to be that useful of an improvement, the biggest pains of lack of type inference were solved in the Java 7 era with the diamond operator which eliminated the need to specify often times deep nested generic arguments on both sides. Now var was basically a bikeshed problem. Between 8 and 11, they improved Strings under the hood to move away from being backed by char arrays. This has huge implications on web services and data processing apps in reducing the memory foot print as most of them wrangle a large amount of json. Also they added an HttpClient to standard library somewhere between 8 and 11 greatly eliminating the need to depend on 3rd parties. They also added the FlightRecorder (although I haven't had a chance to personally use it yet) which improves the the instrumentation story. Not every release is going to have sexy language features but they do contain improvements with direct impact on production software- the String class compaction improvement is the best example, it is not sexy, I doubt it even had a thread on HN but in the real world it measurably improved the performance profile of a large category of applications for free. Release cycles are just numbers, most people in the real world are not keeping up with latest release and instead opting to upgrade to just the LTS releases which are on a much slower cadence of 3-4 year cycles.