DEV Community

Java Isn't Verbose – You Are

Adam - The Developer on October 10, 2025

Every week, some developer crawls out of their legacy codebase to announce that Java is "too verbose." They'll tweet about it. They'll mention it i...

Read full post

Mariusz Nowak • Oct 13

new User("Alice", 30, "alice@example.com", true);

With this notation you significantly loose on code readability. What true actually does here?

In other language it's solved with named params or object literals passed as params. Not sure what are the options for Java

Adam - The Developer • Oct 14

I agree. but there are idiomatic ways to make this cleaner.
You can use the builder pattern:

User user = User.builder()
    .name("Alice")
    .age(30)
    .email("alice@example.com")
    .isActive(true)
    .build();

it’s a bit verbose, but that’s the tradeoff: explicit over magical.
Every language picks a poison — Java just happens to prefer readability over shorthand.

Mariusz Nowak • Oct 14

That looks as best approach to me. Thanks for pointing this out

Zir Teq • Nov 5

I mostly agree with the article, but still..

I think I found the verbosity in the example. It's in the u -> u of the lambda.
In Kotlin or Scala we have defaults for that and it's six to three times shorter (just _ or it).

In Java we can optimize it to .filter(User::isAdult), but then we get to the actual verbosity problem. Four new lines, including the one conventional empty line (thankfully not two as in Python) before or after the declaration:
public boolean isAdult() { return age >= 18; }

In C# that's a one-liner and you don't even need an empty line one before or after, without breaking any styling conventions:
public bool isAdult => this.Age > 18;

As for Uncle Bob; he now found Clojure, which if well written, isn't even fair to compare in terms of verbosity.
(->> users (filter #(>= (:age %) 18)))

Aviad Cohen • Nov 10 • Edited

Regarding your C# preferred-one-liner, how about that:
Predicate<User> isAdult = user -> user.getAge() > 18
One-liner (for those who appreciate it, as if it's the holy grail of coding), using common-known terminology (Predicate), I would also claim it's more concise: Who's this? Better be expressive: it's a 'user'.
(and yes, you can also spare the getAge getter, which no one actually writes (or has to read) nowadays: Predicate<User> isAdult = user -> user.age > 18 ; I personally prefer the getter.)

Not sure who sees this line (->> users (filter #(>= (:age %) 18))) and feels a lack of verbosity is something to appreciate... :)

Boris • Oct 11

"Let's make this more enterprise" – this is a startup, not Boeing.

Literally lol'd!

morganllewellynjones • Nov 2

These are good points, but a language is not just a language, it is an ecosystem.

I don't think most Java developers are start-up developers attempting to emulate enterprise. A lot of them are enterprise developers. You read a lot more Java than you write in these kinds of situations.

There's also a lot of conventions that can be dropped at this point, but have not been. Pick up any book on Java written in the last few years and it will still recommend writing getters and setters for all of your properties (they will mention records, but most of their examples will not use records). Many modern Java examples will also continue to avoid var. When senior engineers who guide new engineers learning into the ecosystem and existing codebases continue to push for the use of old practices, it matters less that it is technically possible to write code in a cleaner and more modern way. Conventions take a long time to shake.

Linh Nguyen • Nov 6

Some additional information I need to add (so that I created an account):

That number 47 sounds like this is a post written, or at least assisted by A.I.
Records can be null
Using Optional everywhere is an invitation to performance hit, may not be noticeable, but it might add up. I'd suggest using Optional only for nested null check, and wait until JEP 401 is finalized
case null, default -> "Unknown" can be just default -> "Unknown", default can handle null case.

Other than that, this post is really, really cathartic. To the hell with the old bloated development mentality.

Adam - The Developer • Nov 10

haha i really need to publicly address the " Records cannot be null " part because alot of people are confused by it. what i was trying to say is, if you design your data to be non-null by design ( validation, etc. ), then you don't even need the Optional.

and thanks for pointing out 3 & 4.

and no AI there, still human here. but ill take that as a compliment lol.

Aviad Cohen • Nov 10

Great article!
Almost as if someone got into my head and spelled everything lies there out, to the extreme.. :)

I would claim an even more extreme statement: verbosity isn't always a bad thing, or something to avoid.
Sure, you can exaggerate with it and be too verbose, and that might harm your code, but being less and less verbose is also not a good place to be.

Eventually, most of the time, most of us usually read code (and not write it). Verbosity, to a certain extent, serves this purpose.
No one wants to read cryptic lines of code that only one person at the office might understand (regex people - I am talking to you!).

I teach students Java technology and ecosystem.
As an example, I show them this line:
class Student extends Person implements Comparable<Student>, HasName
It's (almost) a valid English sentence, expressing the intent and meaning behind every word (Students extend a person; it aims to implement something called Comparable, etc.)

IMO, the alternative using common developer-characters (:) instead of pure, simple, meaningful English words (extends, implements) is not something to be proud of, or push for.

We gain nothing from this sentence Student : Person, IComparable, IHasName, but even my mother can read Student extends Person implements Comparable<Student>, HasName
:)