> I'm honestly never quite sure what people mean by "verbosity" in Java.

Java improved with "var" keyword (use with caution!) and introduction of records. These are not the only code-shortening features (there are e.g. interface methods, diamond operator, lambdas, convenience "of(...)" methods, even "fluid style"), but they, used well, can really reduce verbosity.

Also, a lot of verbosity in Java came from people going off the rails with design patterns to hide crap multiple levels deep in a file with 5+ words in the class name.

If you have a hammer everything’s a nail.

Frameworks like Spring/Spring Boot kind of force that as well with their runtime creation of proxy classes.

I'm surprised you didn't mention the Streams API.

Much of the verbosity came from the false presumption that every field in every class needs a public getter and setter. (I cannot express in words how terrible this is.) Some can come from the framework, mostly poorly-designed ones.

I think Java 11 and higher are reasonably terse/expressive without being overly dense.

Remind me, why doesn’t Java have object-properties yet?

So far the only reason I’ve concluded is Java’s language designers’ egos were so damaged by C#, Swift, Kotlin, TypeScript, etc that after dogmatically denying the developer-productivity benefits of properties for the past 20 years that to concede now would mark the end of Java as a language entirely.

...I kid, but seriously I haven’t heard any compelling argument from the Java camp yet for refusing to add this feature. Object-properties are easily the lowest-hanging-fruit with the biggest productivity-gains.

Heck, even some of the most popular C++ compilers support object-properties as proprietary extensions.

It's so crazy - with all the huge and radical features they've added this would surely have been so simple by comparison and yet added more value than about 80% of the things they've done. It's about half the reason I still use Groovy now since Java has solved most of the rest over time. But I just cannot go back to writing getters and setters!

I believe the Java lang team simply dislikes the Java Beans convention, and if they see a better future, they rather not maintain properties forever.

I think the current future view is Withers ( https://github.com/openjdk/amber-docs/blob/master/eg-drafts/... ).

Couldn’t agree more, the madness of idiomatically adding setters and getters to every field was something I ended up putting an end to in my last gig, and my life improved immeasurably as a result.

I think I'm going to convince my team to get to 16 (with records) before I can convince them to stop adding getters and setters everywhere, but just out of curiosity... how did you manage to make this happen?

Well - I was the boss :) so that helped. But I’d also taken over a fairly unhappy and unproductive team that was ready to try new stuff. I’d been out of the game for a few years and had some fresh perspectives too.

So I did some small standalone projects and demonstrated how much easier life was with this and other (more significant) changes. For example, we had loads of operational problems with dependency injection - the usual cognitive and debugging issues - so I threw all of that out too, along with the frameworks that implemented them. Things started booting in a few seconds instead of minutes and I’d say the lack of setters/getters was mostly done because I built trust in my team that I was making their lives better so they just followed me.

Probably not the answer you were looking for but there was friction from the devs and in the end I just showed them how much nicer life could be...

Kotlin property access solves this. You access to the property but behind the hood it will call the getter/setter if it exists.

I agree with your points here, but just want to add that, while Java's generics are better than the non-existent generics in Go, I still find Java's type system to be really subpar for today's era.

The type system is not strong or expressive enough to do full type erasure, but then we're stuck with type-erased generics, so it's just incredibly frustrating.

Sorry that I find it necessary for yet another answer to your verbosity question, but: The real verbosity is in the standard libraries. What would be a one-liner in any other language is usually at least 2, often 3, and sometimes enough that you end up writing your own wrapper function or library. Especially noticeable is the agony of Lists & Maps, which are first-class citizens in most languages (classic job interview question: what is the difference between ArrayList and LinkedList? Real answer: Nobody actually uses LinkedList).

The stdlib often seems to be written by people who had no intention of using it. I guess maybe this applies to C++ as well, so for some folks it seems normal.

There is List.of() and Map.of() now. And I would say, Java has one of the better standard libs out there in my opinion.

About verbosity: you needed to define classes for so many things. Eg you want others to hook into processing in certain places. So you create a listener interface with some methods. And the provider needed to work with those, and the consumer also needs to work with them.

In modern Java maybe you can make do with functional interfaces and lambda, but it doesn’t always work I think.

And in emacs: the provider does run-hooks, and the consumer defines a function and says add-hook. Done. Very little ceremony.