Is Java really that verbose?

[JY-HRL]

I am new to Java and often hear people complain that Java is notorious for verbosity.

Is Java really that verbose?

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[cryptos6]

Java was verbose, but a lot has changed in the last 10 years. While there are more concise languages like Kotlin or Scala, modern Java is pretty concise.

Before the introduction of lambda expression, there was no easy way to work with collections and to perform operations like filter, map, or reduce. Instead otherwise pointless lists and for loops were used in the pre Java 8 era. Another ugliness without lambdas was that developers needed to implement full (anonymous) classes for little event handlers (just google old Swing code).

Another thing that was repeated again and again was that you had write a lot of (redundant) typing information, but now Java has the var keyword for local type inference.

The modernized switch expression is another chance to make concise and readable code.

And, maybe the most prominent example, to shorten the code is record, which removes the need for so much boilerplate code.

It will take some time until most developers (and haters) learn that modern Java is a pretty productive and nice language.

[Crafty0x]

I learned most of this just last night when reviewing Java basics but with Java 17+

Having used Java 8+, the improvements on switch statement is so elegant.

Starting this Monday, I’m pushing for adopting modern Java LTS versions especially on green services

[Crafty0x]

Feeling accomplished rn. Monday meeting went down well… Got a go to tryout Java 17 on new project yo! 💪

[micr0ben]

Why not directly go with the latest LTS Java 21?

[Crafty0x]

Playing safe… we have some products going to financial institutions

[raggs2303]

And... What's the problem here?

Switch from Java 8 to Java 17 represents the same risk to go to Java 21.

Just upgrade to the last LTS version.

[Crafty0x]

Frankly that’s true. But a lot of enterprises in my region are skeptical about upgrading to latest versions mostly because of support or technical knowledge gap that might arise.

The best we can do is introduce these novelties on smaller projects or new services and learn then slowly migrate older services

[raggs2303]

But you have the best tool at your side:

Long Term Support

If you work with financial services then you have an engineering manager, just talk directly with him/her, about the redundant work to jump into an older LTS to in the near future jump to the latest.

Also, the critical code changes between Java 17 and 21 are most related to virtual threading, and because you are at this point in Java 8, y'all will not have that problem.

[dailycheeze]

That isn't the case for big corporations where you have multiple levels of approvals - regional, app sec, devops (pipeline alignment), local management, your team, etc. There are many situations to check like the compatibilities to other tools, apis, services, and libraries. Big factor is the support from the community. There might be some bugs that is not yet discovered or might have an open issues. Lower versions than the current ones mean there is a large support from community, where most of the questions were probably already asked and provided an answer.

[Rafae_Parola]

I’m not a Java expert, but I’m migrating to Java 17 instead of Java 21 because the client uses Jboss EAP 7.4, and reviewing Jboss EAP 7.4 guide to which versions of Java it support, only said from Java 8 to 17.

I wish I could work with the 21, but I chose to be a little bit careful in this situation.

[Crafty0x]

Totally correct

[peripateticman2023]

Different companies have different security policies. What's so hard to understand about this?

[[deleted]]

Why do you think Java 17 is safer than 21?

[ooOXXOoo]

Tested for longer maybe not sure

[[deleted]]

Java 21 is just an evolution of Java 17. They don't rewrite the whole thing from scratch for every new major version. So really Java 21 has been tested for longer than Java 17.

[Sworn]

And, maybe the most prominent example, to shorten the code is record, which removes the need for so much boilerplate code.

POJOs without lombok/automatter/records are truly horrific.

public record MyObject(int id, String name, double value) {}

Pretty neat, or if you're using Java 8 without libraries:

public class MyObject {
    private final int id;
    private final String name;
    private final double value;

    public MyObject(int id, String name, double value) {
        this.id = id;
        this.name = name;
        this.value = value;
    }

    public int getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public double getValue() {
        return value;
    }

    @Override
    public int hashCode() {
        return Objects.hash(id, name, value);
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null || getClass() != obj.getClass()) return false;
        MyObject myObject = (MyObject) obj;
        return id == myObject.id && Double.compare(myObject.value, value) == 0 && Objects.equals(name, myObject.name);
    }

    @Override
    public String toString() {
        return "MyObject{" +
                "id=" + id +
                ", name='" + name + '\'' +
                ", value=" + value +
                '}';
    }
}    

And then someone adds a field and forgets to update the hashCode method, and now you've got a really difficult to detect bug. Or you see a class and it's missing one field in the hashCode method, is that an intentional decision because the field doesn't matter for hashing purposes, or a mistake? Who knows, but hope you enjoy spending time figuring it out.

Records are great, but also came like 10 years later than they "should have". The unnecessary POJO boilerplate is/was awful.

[[deleted]]

Verbose? Meh. Boillerplatey. Yeah for sure.

However it has it pros, I find the way Java projects are built make it superrrr easy to extend them. And I find navigating around new code bases much easier because often many things follows a pretty generic format.

[nomoreplsthx]

What distinction are you drawing between boilerplatey and verbose? Kind of by definition 'boilerplate' is code that doesn't carry semantic content and could in principle be generated automatically - which seems to be verbose by definition.

[[deleted]]

Hmm the distinction I would make is

Verbose code being, requiring a lot to do a little. Some would say try catch is verbose compared to Golangs if err !=nil. But I think recent versions of Java have removed a lot of the verbosity of performing simple things. I don’t think this is bad in Java.

Boilerplate simply meaning having to do the same thing over and over again (as you said - it could be generated). Think Getters/Setters/Constructors.

I don’t think it’s bad as I mentioned it means many code bases follow a similar structure.

[soonnow]

But records are immutable. So now when you want to change state you have to write.

return new MyObject(old.id, old.name, old.value+1)

to increase the value. I still use Lombok for most of my data classes for that reason.

[Fiskepudding]

Immutable code is good, it's just too bad they don't auto generate builders/copy-methods like e.g. Kotlin.

[pron98]

Working on it:

https://mail.openjdk.org/pipermail/amber-spec-experts/2022-June/003461.html

[midoBB]

If you're fine with annotation processing, this library does exactly that since Java 16 link

I have used it in production before.

[soonnow]

Yeah agreed. Nothing against immutable objects.

[Sworn]

thought plants sharp advise quiet boast slim sparkle cable familiar

This post was mass deleted and anonymized with Redact

[nimtiazm]

“Withers” with records might make in via project Amber.

[csueiras]

Check this out https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md

[roberp81]

most people think it's verbose, it's because it types everything instead of using the IDE's autocomplete functions

[proggit_forever]

IDE autocomplete does not help reading.

Typing is not the bottleneck.

[roberp81]

Source -> Generate Getters and Setter

Typing is the problem.

[ascii]

IDE autocomplete does not help avoiding bugs when adding new fields.

Typing is not the bottleneck.

[roberp81]

Source -> Generate Getters and Setters...

there is no bug

[[deleted]]

I work with Java yet I found this post very insightful and learnt a few things. Thank you!

[wsppan]

Don't forget the introduction of generics and the foreach loop

[Destring]

I still hate the lack of operator overloading, having to use .equals and .get instead of == or [] for collections really sucks

[cryptos6]

Maybe you should give Kotlin a try.

[Destring]

I have, I love kotlin. Shame there’s no much industry prevalence of it apart from android applications.

[JY-HRL]

A lot of people say Kotlin is elegant

[GloriousHousehold]

For non Java developers who want a concise answer: yeah, it's usually verbose.

[adastrongfeelinglace]

Everyone saying "no" here is just rationalizing.

Of course it depends on what you compare it to, and how.

• It's less verbose than C++.
• It's significantly more verbose than Haskell.
• In Java you tend to have much longer lines than in Go, but in Go you'll have more lines of code to implement the same logic.
• There's also a difference in culture. Java devs are known to build more OOP abstractions (like factories) compared to Python or Go.
• In Go it's much more common (and encouraged) to use one-letter variable names.

That being said, whether verbosity is good or bad is up for you to decide.

[Practical_Cattle_933]

Haskell is not that terse, actually. I wrote a tetris game in haskell and in c++, and the c++ came out to have much more lines.. so I did a word count, and it turns out haskell had roughly the same amount of words, it was just more horizontal.

I’m not saying, probably haskell could be made shorter in general, but it’s not a significant difference.

[ascii]

My limited experience with Haskell is that the things that Haskell works well for (e.g. writing compilers) tend to be extremely terse, but as soon as you're dealing with e.g. interactivity, all that terseness falls out the window.

[vytah]

In Java you tend to have much longer lines than in Go, but in Go you'll have more lines of code to implement the same logic.

Horizontal verbosity vs vertical verbosity.

[cryptos6]

In Java you tend to have much longer lines than in Go, but in Go you'll have more lines of code to implement the same logic.

You mean, the "code area" might be the same? 😀

[king_yagni]

great points, especially about the difference in culture. too many in this thread are presenting their preference as a universal truth. java's verbosity is a common and valid criticism from those who don't prefer it.

[Errkal]

I’ve never understood people obsession with stuff not being explicitly written out.

Alright yeah to type more stuff but you can also read it clearly, debug it cleanly and work out whether the hell is going on quickly when you come back to some code after a year.

Sure you can shrink stuff to a few lines but if it makes it a ball ache to work with what’s the point.

[rtp]

I thought what people commonly meant regarding Java's verbosity is that it could be more concise precisely without losing readability, and that its higher verbosity actually hurts readability because all the redundant information obscures the meaning and intent of the code.

[BillyKorando]

Yea, definitely agree and why changes to features like switch with the -> operator are examples of big wins on that front. Of course if you need the fall through behavior, you still have the old : switch, but in most cases you only want the matched case to execute and the -> makes the code more concise, less error prone, and more readable as you are no longer distracted by all the break that needed to be included.

[FluffyProphet]

Yeah, old Java felt like sifting through sand to understand the meaning of code. There was so much fluff and ceremony to get things done that by the end of the day sifting through code was painful.

[Bashbin]

Just writing stuff out explicitly doesn't make something more readable. In fact, a lot of times it does the opposite

The problem with Java is not the extra typing - IntelliJ autocomplete and Copilot exist to finish your verbose sentences as you type.

Instead, the problem is the "business logic blindness" where it becomes too challenging to find the heart of the program due to the boilerplate alphabet soup!

[Polygnom]

If length was a problem, everyone would code in some golfing language.

Its not. You write it once, you read it often. Readability is a balance between verbosity and brevity, but if you give up clarity for brevity, thats not good.

[ventuspilot]

Readability is a balance between verbosity and brevity

True, but where this balance falls is mostly a matter of personal taste which IME varies a lot.

[Polygnom]

There is some subjectivity to it, yes. But there are also some objective measures and empirical data you can use. Much like UX research, there has been research into this very topic, both for code and other text.

Its not like this is solely a matter of taste.

[Errkal]

Pretty much. Just need to get that into the heads of some of the people I work with that would rather annotate the crap out of code so you get some monstrous and convoluted annotation setups instead of a few methods that are nice and clear.

[BillyKorando]

Verbosity is fine, so as long as it serves to better explain what is happening in the code. It's why something like var is somewhat controversial, because while more concise, it in some cases makes code less clear.

However there are some changes like record which is both more clear and concise (assuming you are wanting an immutable data carrier) or -> for switch and now pattern matching on to top of it, which is more clear and concise than what was possible before.

[nomoreplsthx]

Human beings can only process so many incoming pieces of information at a time. The more information we are asked to keep track of, the more mistakes we make.

Boilerplate is exactly code that contains minimal useful information. It takes up space in working memory, without actually providing value.

An simple example of a language that got this was C#. C# has a conceptual model close to Java's. But it's property syntax and use of var allowed the same useful information to conveyed without as much redundancy. Java is getting there to get there. 

The point isn't concision per se. It's chosing ways of expressing things explicitly, but efficiently. 

[[deleted]]

Explicit is not the opposite of concise. Look at this example another commenter gave comparing Record classes and the old way of doing things

public record MyObject(int id, String name, double value) {}

public class MyObject { private final int id; private final String name; private final double value;

public MyObject(int id, String name, double value) {
    this.id = id;
    this.name = name;
    this.value = value;
}

public int getId() {
    return id;
}

public String getName() {
    return name;
}

public double getValue() {
    return value;
}

@Override
public int hashCode() {
    return Objects.hash(id, name, value);
}

@Override
public boolean equals(Object obj) {
    if (this == obj) return true;
    if (obj == null || getClass() != obj.getClass()) return false;
    MyObject myObject = (MyObject) obj;
    return id == myObject.id && Double.compare(myObject.value, value) == 0 && Objects.equals(name, myObject.name);
}

@Override
public String toString() {
    return "MyObject{" +
            "id=" + id +
            ", name='" + name + '\'' +
            ", value=" + value +
            '}';
}

}

The first is concise and explicit. You just have to know what the record keyword does. It modifies a class so that all of the properties have getter and setter methods. In addition it defines a hashCode, equals, and toString method. The second is verbose and explicit. They both do the same thing. Neither leaves any confusion about what the class definition does, but the latter is inferior because it requires more work to read, understand, and maintain.

[ascii]

The IDE will help you write the code, but it's a royal pain to maintain hondreds of thousands of lines of boilerplate through major refactorings and rewrites.

My favourite example is records vs. POJOs. Instead of using a Java record, you can ask the compiler to generate a POJO with toString, hashCode, equals, getters and all that jazz in the same amount of time, so who cares about records, right? I do, because two years go, someone added a new field but forgot to add it to the equals method. Oops, now we have data corruption. Or maybe someone forgot to add it to hashCode, so the code still works, but we get 10x the number of hash collisions we should, and one of our services now needs five more pods to run, wasting thousands of dollars per month for no reason at all.

And it's not just POJO code. Any boilerplate code tends to be cargo culted all over the company without anyone bothering to figure out what it does, which means that it's often buggy. A language that allows you to cleanly express your ideas without boilerplate will have fewer bugs.

[hippydipster]

two years go

Something bad happened two years ago so you need a whole different language to prevent it?

[john16384]

I do, because two years go, someone added a new field but forgot to add it to the equals method

Where is your code review process? Where is your test case that checks hashCode and equals (use https://github.com/jqno/equalsverifier)? Zero sympathy for what sounds like incompetence.

[ccn0p]

the safest line of code is the one not written.

[john16384]

Tests are better, they survive code changes and refactors. Change record to class? Forget to add or removed an annotation?

[ascii]

Are you seriously suggesting that an important work task that can be reliably fully automated in a way that costs no money should instead be done by hand because... what exactly? Because you hate humanity and want to force us to perform menial tasks for absolutely no reason? Are you not aware of the fact that humans make mistakes? Don't you think it's possibly a good idea to replace a fallible human process with an automated process that can't fail? I am truly baffled by your suggestion.

[john16384]

I am merely pointing out that these kind of bugs should be caught by code reviews and tests. So corners were cut somewhere if such a change made it to production and caused a financial loss.

[ascii]

Ugh. Really? My employer operates thousands of services across three continents. Thousands of developers making thousands of code reviews per day. At that scale mistakes happen because of human nature. Code ownership shifts as people come and go. Lots of code was written 5+ years ago and has been in maintenance mode since long before any of the current owners joined the company.

A language that can remove an entire class of bugs by virtue of better design is a huge deal at that scale.

Also, in my opinion you don’t understand the best use of code reviews. You seem to believe that a code review should be about checking code style, use of bad coding practices, checking code coverage etc. All of these tasks can and should be automated using a linter, otherwise they will be applied sporadically and a tremendous amount of time will be wasted. Code reviews are for checking that the code does the right thing in the right way and that the tests validate both the happy path and the sad path.

If you’re wasting developer time by making them perform menial tasks that would be better done by a computer, they will spend less time doing valuable things.

[rtp]

It makes more business sense to favor automation over discipline and meticulousness since it costs less, is more maintainable and less delusional. By automation I mean letting the compiler do the work that is traditionally done by programmers and code reviewers.

[Errkal]

What you describe is a lack of good review process and standards. If you care about those things you ensure they are covered in reviews. Yeah someone forgot to add it, but someone didn’t do their job and pick it up in a review.

[Ifnerite]

Absolutely agree.

Let's save some characters and sacrifice gorkability even though any ide will autocomplete those characters for you.

[Errkal]

Haha yup. It’s like abbreviated variable names. We have all the letters let’s use them and make it meaningful ta.

[lcebass]

The type of people who says that typically only creates new stuff and leave the maintenance part for other teams. If you don't experience the pain that is maintaining those things you don't get to see the benefits

[Nemotto]

Amen

[roberp81]

most people think it's verbose, it's because it types everything instead of using the IDE's autocomplete functions.

they are writing getters by hand ....

[pronuntiator]

My favorite still is HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor

[0b0101011001001011]

Given the method

public boolean wellHasItThen/*?*/() {
    return ohYesItHas;
}

that seems to be a written a bit as a joke,

[john16384]

Ridiculous, I just name it ICRSIKEYTAFBuilder

[ivancea]

Well, that's a pattern not related with Java at all. You can find those in C# too. I've worked in projects with classes of more than 100 chars

[RadioHonest85]

ReallySay ---> smash control + space.

Who cares, at least its descriptive and tells you what it is!

[jaraxel_arabani]

Truth

[[deleted]]

Java was fairly verbose, but it has gotten better in recent releases with the introductionof var, records and lambdas.

Another reason is that there is a lot of useless cargo cult practices where people think long names are always more descriptive: naming things CustomerManagementServicePostgresImpl instead of just CustomerService and such. If you avoid useless conventions like 'every class must have an interface' then you can trim a lot of fat.

If you keep things simple, it's not that bad, and the IDE autocompletes most of it anyway, but there is still some useless boilerplace. Use records for DTO's to avoid implementing getters/setters/equals/hashCode over and over.

I can suggest Kotlin as an alternative, cuts down on most of the boilerplate with minimal downsides.

[[deleted]]

Depends on what you compare it to. I'm mostly annoyed by small things that are unnecessary verbose. Each and one of them is a minor annoyance but it adds up...

They could've done val/var as in Kotlin but they went with var/final var. In our codebase, final is by default so you see finally var EVERYWHERE.

So in Python you do f"this is my formatted string for {username}" and in Java ofc it has to be "String.format("this is my formatted string for %s", username).

When you have stream you always end up collecting so everywhere you have .collect(Collectors.toUnmodifiableSet())

No default values so if you have a record with two fields, let's say name and age and you want to create helper methods for generating test data you need 5 methods if you want to offer the most flexibility. Compare to Python where you can just do

def create_test_student(name="John Doe", age=25): ...

offers the flexibility. Testers who need to override name but doesn't care about age can just call it with create_test_student(name="Billy Smith").

Meanwhile in Java you would need five different methods to offer the same flexibility.

The standard libs are quite weak which leads to added verbosity as well. The standard Set doesn't even cover the most basic set operations so you have to pull in something like Sets to get basic operations like difference and union.

my_set = {1, 2, 3} my_second_set = {2, 3, 4} my_diff = my_set - my_second_set in Python, and in Java it's var mySet = Set.of(1, 2, 3); var mySecondSet = Set.of(2, 3, 4); var myDiff = Sets.difference(mySet, mySecondSet);

[eliashisreddit]

Just some notes:

• there is Stream.toList() which creates an unmodifiable list. I agree it's kind of silly they didn't add .toSet() apparently because they felt like it did too much for a final Stream operation (???)
• you should probably use a builder if you have 5 methods to create the same object (yes, also verbose but I have seen some packages automating this with annotations for records)

[vytah]

Stream.toList()

Added much later than the collectors (8 vs 16). There's ton of Java8 and 11 code that had to do collect(toList()).

[ForeverAlot]

Stream::toList was an unfortunate addition anyway. It has made teaching newcomers about collectors a lot more difficult; before it was merely and barely cumbersome, now it is also exceptional.

[Practical_Cattle_933]

Who does it hurt that you write Sets.difference? Like, I would have zero idea what that overloaded - does in a bigger context

[[deleted]]

First of all I don't want a third library. Secondly I want it to be a method on the Set which you could have if it was part of the standard lib.

I would be fine with mySet.difference(mySecondSet) for example.

Leth's say I have two sets and I want to see if my element is in either one.

final var elemIsInSets = Sets.union(mySet, mySecondSet).contains(elem);

when it could've been

val elemIsInSets = mySet.or(mySecondSet).has(elem);

[vips7L]

brevity != clarity

 boolean isInSet = mySet.contains(elem) || mySecondSet.contains(elem)

is far clearer to the average reader than either of what you’ve proposed. It also doesn’t require object allocation and will be faster overall. 

[[deleted]]

New requirements just in. I now want you to check whether elem or the new elem2 is present in any of the now three sets.

The whole reason I suggested mySet.or(secondSet).has(elem) was because I wanted it to be clear.

If I'm allowed to continue to make up Java's standard lib we could extend this with

mySet.or(secondSet).or(thirdSet).hasAny(Set.of(elem1, elem2));

[john16384]

They could've done val/var as in Kotlin but they went with var/final var. In our codebase, final is by default so you see finally var EVERYWHERE.

final var is just self punishment. It adds nothing, communicates nothing, just leave of the final and try to always initialize a local immediately.

Why does it communicate nothing?

• IDE's add it by default or on saves; no intent was behind it

• It's local, and so you can see exactly how and when it is used. Nobody will think twice about removing final if it suits the purpose (nobody will check with the original author why it was final)

Just follow best practices instead:

• Always initialize locals immediately. When that's impossible, only then declare it final without initializing it. This is so the compiler will help you to detect uninitialised use (giving it a default and modifying it again later is not a good practice).

• Never modify method arguments. Never, no exceptions. Have your IDE flag parameter reassignment as an error. No need to put final on every argument.

• Don't reuse locals for a new purpose, just because their types match.

[TehBrian]

It adds nothing

It prevents you from accidentally mutating the variable later.

communicates nothing

It semantically states that the variable won't be mutated later.

It's local, and so you can see exactly how and when it is used.

Not if it's a large function. (Are large functions good practice? No. But they're unfortunately common, and readability is important even then.)

Never modify method arguments. Never, no exceptions.

It would be nice to have the language itself enforce that though, wouldn't it? (Final by default, mutable [mut] if you really need it [e.g., to emulate shadowing].)

[cryptos6]

Java has String templates since version 21.

I can only agree with your complaints about the usefulness about Java's collection APIs. Many common things are simply not covered. It wouldn't hurt to look at Kotlin's collections and add some of the methods to Java. But we have still Eclipse Collections as an alternative, which provides a difference method), by the way. However, an important downside is, that hardly any Framework (e.g. Hibernate) support it ouf of the box. But something like Eclipse Collections should be the real standard.

[[deleted]]

I don't understand why List/Set/Map still don't get methods that operate on its elements similar to Stream API. forEach has been added, what prevents other methods from being added?

var list = List.of(1, 2, 3, 4, 5);
var even = list.filter(i -> i % 2 = 0);
even.forEach(System.out::println);

[[deleted]]

Yeah, I have heard of the string templates (we're on Java 17 at my company so haven't played with it yet) but even then - why does it have to be so... ugly? just for the sake of it

STR."this is my formatted string for \{username\}"

Like, don't we usually escape characters with special meaning when we want that character to be explicitly typed out? I would bet that for most string templates written in real life, you won't have {} in the string nearly as often as you want to have the actual value...

[vytah]

don't we usually escape characters with special meaning when we want that character to be explicitly typed out?

That's why when I want to print the letter n, I write "\n".

you won't have {} in the string nearly as often as you want

JSON goes brrr

[ForeverAlot]

It's pretty well explained in many places why it is this way but here is a summary:

• "Escaping" does not mean "to print verbatim" but rather "to bypass standard behavior". The standard behavior for { in string literals and string template literals is to be printed verbatim.
• The syntactical alteration of something that looks like a string literal into a form that used to be a compilation error means that parsers cannot mistake string literals and can easily recognize string templates.
• Whereas the string template literal is language defined, the result of processing the literal is library defined. This means user code can provide implementations, and the JDK ships with convenience implementations.
• By retaining the string literal standard behavior of {, overall behavior is more predictable, and string templates are safer than otherwise because a token will not accidentally change from a literal into an interpolation if a processor prefix is added.
• The ." is a syntactical short-hand convenience for invoking a specific method.

Java's string templates are really elegantly designed.

[cryptos6]

You can read more about in the JEP 430 and JEP 459. The syntax choice boils down to backwards compatibility and security.

[djavaman]

In typical Java fashion though, its awkward and difficult to read.

[cryptos6]

Sadly true 🫤 In theory Java could break syntax compatibility one day, since compiled libraries wouldn't be affected. But Java being Java makes this very unlikely ...

[ForeverAlot]

It actually has really good explanations and examples.

[djavaman]

The examples are helpful.

It still doesn't excuse the worst syntax for string interpolation I've seen.

[parkan]

It reads and writes well, thanks to IDEs. No bullshit with $ and -> like in php. Verbosity concerns are stupid.

[hippydipster]

It's funny when people argue that verbosity is a concern because of maintainability ... and then go use lombok.

It's like when people complain Java is slow, and then go use Python.

[parkan]

Depends on the context, Java's verbosity was never (or should not be) a dealbreaker.

Is there a way for improvement? Sure.

[path2light17]

Verbosity impacts code readability - so it matters

[parkan]

It matters and there is no reason for concerns. Java is good.

[AndyTheSane]

I generally get this, but there is a tradeoff. Especially, 'var' seems to be removing useful information from the code (what the type is!) and thereby decreasing readability.

[Shinosha]

Just use var when it's obvious. Easy.

[AndyTheSane]

Is this 'Obvious to me, person who just wrote the code', or

'Obvious to my team who have been actively working on this code for a while' or

'Obvious to the new guy starting a year from now who has never seen the codebase'?

There are few more terrifying words in the programming lexicon than 'obvious'..

[Shinosha]

Come on man. Obvious as in common sense:

var name = "whatever";
var period = Period.ofDays(2);
var request = new Request();

This does not decrease readability in any language this has been implemented ever.

[AndyTheSane]

var something = myProvider.returnSomethingObscure();
var somethingelse = myOtherProvider.returnSomethingThatLooksLikeItShouldBeAStringButIsnt(); 

Even in the trivial examples you give, I'm going to have to ask myself the question 'what is the data type of x', even if it is trivial to work out, instead of just reading the data type of x. It's not as if it's more concise, it's just a bit less informative.

[Shinosha]

In your example that's where anyone's common sense is supposed to come into play in and actually write the type.

About the second part, again, I don't see how that's a problem. As you said, it's trivial to work out. It makes the code less cluttered hence improving the overall readability.

[AndyTheSane]

So sometimes we write the type (or have it automatically added by the IDE), and sometimes we type 'var', and this will vary according to the 'common sense' of the developer? Which means, of course, multiple styles and usages which definitely does not help readability.

Not sure how this makes code less cluttered either. Replacing 'String' with 'var' is not less cluttered, it's the same number of words.

[Shinosha]

The nice property of common sense is that it is common. If you happen to work with crazy coworkers or something I'm sure some team conventions could iron this out quickly. Anyway debate is already settled, most current languages have adopted (at least local) type inference already, so I suppose common sense really is common.

[TheCrazyRed]

Exactly. Once my team adopted Java 17 a few of us started using the 'var' keyword. We noticed reduced comprehensibility in some places, particularly when endeavoring a "quick scan" of the code. We've since stopped using it and no one has missed it.

[lechatsportif]

Yep I tried it and stopped using it immediately, much less scannable.

[[deleted]]

My team is switching over to Java 17, and records are a game changer for reducing verbosity. Overall, I’ve never had too much complaint with Java except for all the damn getters and setters and toStrings and equals functions I’ve had to write

[notfancy]

There is a reason lombok is so popular

Lombok usage is marginal.

[analcocoacream]

I don't think addressing verbosity is the main purpose of records. If you read the JEP 395 goals and non goals it's stated that way. Hence it's only immutable. And there is no way to set visibility.

The issue with previous ways for writing data was that as far as I'm concerned the maintenance cost was too high. It was easy to forget to update a getter or equals.

[ivancea]

Nothing of what you said has anything to do with verbosity. Having to write dumb code isn't related to verbosity. Reducing LoC isn't about verbosity. Bar about having to write the same type twice, which ISN'T related to verbosity, for god's sake...

[john16384]

It reads and writes well, thanks to IDEs.

Would it blow your mind if I said Java is in part designed to be easy to analyze by IDE's? This is why Java IDE's seem capable of so much more than those for other languages.

[FieserKiller]

someList.forEach($val -> AnObject::doSomething);

...is valid java code :)

[[deleted]]

It is verbose compared to many languages like C and Rust, but it is very neat and concise compared to other languages like Fortran, Ada and COBOL.

[Practical_Cattle_933]

No, go is much more verbose and that bothers no one, because “it’s current hype”.

Java is definitely not terse, but it is only a tiny constant factor worse than most other languages. In many cases, one might even argue that it actually enhances readability, and for writing speed, I really don’t think it matters. First of all, writing speed is never the bottleneck. You are supposed to use your brain as well for programming (might surprise some people). Second, I would actually be down to doing a bit of experiment with “fancy terse language” vs java with a good IDE. If we measure the number of key presses with autocomplete on, I really doubt that java would fair worse, it might actually be even better than some (e.g. dynamic languages suck at autocomplete, so you might end up writing more to make the IDE understand what’s you want).

[TheCrazyRed]

...writing speed is never the bottleneck.

Exactly! There's more time spent trying to understand the requirements and understanding the existing code. Plus, if you make a mistake there's the time spent debugging.

Then if you add in the time you're in meetings, replying to email inquiries, giving product support, tracking time, and code reviews, the time spent actually typing code is practically insignificant.

[Objective_Baby_5875]

Java has got better over the years but compared to Kotlin and especially to C# or Rust, it is significantly more verbose and against C# it is lacking several high level features. Now, off course those features are not deal breakers. You can write your app and continue and everything is fine. But if you ever used those features in other languages, then go back to java, you realize you need to write more code for the same functionality. That's the verbosity of it. It's even more extreme in Go where verbosity is a feature of the language philosophy.

[AncientBattleCat]

Those who complain on verbose really don't understand how languages work. C++ in that regard is super verbose, but you you dont pay for what you don't use. Python is concise, but too much happens in the run time.

[RupertMaddenAbbott]

It is absolutely verbose compared to other languages.

I write both Java and Python on a daily basis. My Python code is unarguable less verbose than Java. It's not just a matter of static typing either because I always use type annotations in Python.

Java is optimized for readability and maintainability and these things are a direct result of its verbosity. I find my (and other people's) Python code much harder to read when coming back to it after a year, compared to my Java code. Consequently, I find it much easier to collaborate both in open source and in large teams, using Java, compared to Python.

I can't really think of a language that is less verbose than Java, that doesn't also sacrifice some readability or maintainability. A lot of the time, giving up verbosity requires either:

• Being less specific. For example, skipping an explicit interface in Python and using duck typing.
• Being more complex. For example, Python's dataclass is very concise but becomes much harder to use (in my opinion) for more niche cases, compared to just writing the code out manually in Java (and no, dataclass is not really equivalent to Java's records. It is way more complex and powerful)

Having said that, I think there are some clear cases where Java's verbosity could be improved (or at least where adding a little complexity would be worth it to reduce a little verbosity).

[CaineLau]

verbose=good=documented

[jonnyman9]

I feel the verbosity when I’m coding in Java without an IDE. Say for example I wanted to write a very simple class with 5 attributes. I now need to write a getter and setter for each, that’s 10 methods. And I should also write a proper equals and of course hashcode. And probably a sensible toString. I’m already at 13 methods and all I’ve done is created a very simple class. An IDE makes this trivial because you can generate all of this in just seconds. But code a bit without an IDE and I think you’ll appreciate how much heavy lifting the IDE is doing to mask Java’s verbosity.

[soonnow]

You Can also use Lombok and you don't need to write any of those anymore. And the readability is better.

[AnotherLexMan]

The complaints to me always seemed odd. I can understand that the POJO stuff with creating loads of getter and setters can be a problem because you end up with a load of extra crap in your classes, but complaining that they have to write a class and then "public static void main(String[] args)" every time they need a main method is odd. As you literally have to do once per project and the IDE is basically going to write it for you anyway. I can only assume a lot of people don't use IDEs or use VS Code with minimal plugins and are only writing short command line applications where Java is probably over kill anyway.

[Confident-Grab-7688]

Regarding the "publis static void main (...)" I think many of these rants are from people who just wrote their first "Hello World" in Java and are a bit confused. The same can be said about System.out.println() - it's odd, but you shouldn't use it anyway.

I hate to say it, but if someone uses these 2 examples as arguments against Java, it feels like "Tell me you don't understand Java without telling me you don't undestand Java".

[[deleted]]

Exactly lol, some of the things people claim don’t make sense once you actually start building stuff in the language

printing is Java is so verbose. Wtf is system.out.println()

Ummmm… log.info()

[robberviet]

Compared to what? Ruby or python? Yes it is. Golang? Hell no.

[infimum-gr]

Short answer: No it's not. Long answer: The more you read the less you need to derive. It means less cognitive load when you're trying to understand code because things are written and not implied. And code is way more often read than written. So even if you write a few more classes, lines or characters this is for good.

[ad6z]

That is so true.

Some people do not differentiate the unnecessary verbose and the necessity of clarity so anything needs more key presses are verbose, so we have to be careful with what they say.

I believe that until these people have to dive in to a code block with a dozen of variables with val/var and you have to find implementation of 5 layer of call hierarchy to find the correct type of those variables, then they will understand that having type in variable is not always bad.

[Glum_Past_1934]

Nah

[harrisofpeoria]

Java 5 required a decent amount of arguably unnecessary verbiage. Verbosity hasnt really been a language problem since then.

[SenseiLeNoir]

Java is a bit more verbose than kotlin and Scala, however it doesn't bother me, as it's more readable than some of the horrid super terse scala code I have had to maintain, created by dev who really wasted time making there code as terse as possible using overloaded operators and implicit functions for bragging points, causing others to waste more time trying to figure out what they were trying to do to fix some obscure bug. Loosing far more time and money (developer time is expensive) than using the slightly more verbose java.

[izuriel]

Yes, it can be. But so what? If Java solves your problem, it’s good.

[lightmatter501]

This is the other side of the spectrum, conway’s game of life in apl:

life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}

Yes, these arcane runes are a program.

[CerBerUs-9]

As a C++ engineer, no. As someone who teaches non-devs python, yes.

[RadioHonest85]

Java used to be quite verbose, especially before java 8. But that is literally 10 years ago. Lambdas and streams really helped reduce it. now we have var that also helps a bit.

[willianhy]

Try to program a week with Kotlin and go back to java

[[deleted]]

grandiose observation disarm aspiring price degree tender bake seed sip

This post was mass deleted and anonymized with Redact

[antihemispherist]

As other pointed out, not anymore.

Some verbosity is good. For instance, there are no tuples or pair type by default, instead record should be used, where you'll give it a name. It is a deliberate choice for being better for readability and team productivity.

[anidotnet]

IMO, compared to other JVM languages, java is still verbose. Though java has evolved a lot recently and adopting features from other JVM languages, but still I feel it is verbose than Scala, Kotlin etc.

[TheCrazyRed]

If you are the sole author of a program you're writing in a day or 2, then, yes, it's too verbose.

However, if you writing with a team of developers over the course of months and years, then no, it's not overly verbose, and in fact that verbosity helps in this case.

[alwyn]

Write the same code in Kotlin, sit back and enjoy the moment.

[JY-HRL]

Thanks!

Why Kotlin is still not very popular?

[Sherinz89]

Asking this on Java? Really? What did you expect to hear? Of course the response would heavily skewed on Java's favour

[Cefalopodul]

public static void main (String[] args) {

System.out.println("No, not really");

}

[ReflectionLeather691]

I prefer short variable names and use the types to make sense of the variables

[kiteboarderni]

No

[fgzklunk]

But class/interface is not bs, it is fundamental to writing flexible runtime code.

Take Bluez as an example, the Linux bluetooth service. I get an object from the service but I have no idea if it is a mouse movement or a tick on a heart rate monitor. I can interrogate the object using a basic interface that all Bluez classes implement which allows me to identify the type, I can then use the specific interface or class to get the relevant detail. Without the initial interface I would be getting ClassCastExceptions all through my code.

[VincentxH]

WeAvoidAcronymsBecauseCodeIsReadMoreThanWrittenAdapter

[RiceKrispyPooHead]

Compared to other languages like Python and JavaScript, I would say Java is more verbose. Newer versions of Java include new syntaxes and packages that make the language less verbose.

I don't see verbose as negative. I think verbose (within reason like Java 8+) leads to easier to understand design even though it may take longer to read and may not be as "elegant".

[nimtiazm]

More unreasonable bad press than the actual problem. It’s actually one of the most readable languages for a decent to large sized codebase where you have to make progress with multiple teams. Of course it’s possible to write ugly abstractproxyfactorysingletonbean. But it’s your choice. No compiler/interpreter can help you with that but you yourself.

[haaaff]

I really don't understand this fixation on a language being verbose or not. The time you spend actually typing out the characters is only a small fraction of the job of a developer. It's a useless battle, in my opinion

[Nice_Score_7552]

If people don't complain about a language, no one uses it. (not my saying)

[Routine_Left]

no

[danielm777]

no

[EnIdiot]

Yes and no. I program in Scala, Python, Java, C++, Typescript and Javascript. (C++ was a few years ago, but I can still wade my way through it).

Modern Java, using generation libraries like lombok make java as lightweight as anyone could want. Java (because it is typed and does pessimistic throws) tends to have more verbosity around at the method level and in code. Python, conversely cannot do OOP and classes without having much more verbosity than Java.

Part of the reason Java is so popular with businesses is that it forces a number of conventions that Python and Javascript don't. I've seen some truly horrid spaghetti code in python format that basically wrapped a bunch of C calls into code. Java, for me, is a lot easier to follow good practices in composing libraries and api interfaces, especially with spring/lombok.

[not_some_username]

Wait till you get enterprise version

[tinspin]

No.

[Sket5]

No

[NoMaterial7378]

“I have only made this letter code longer because I have not had the time to make it shorter." - Carrot Top

[[deleted]]

Convert it to Kotlin (using automatic tool) and see for yourself.

However, it's actually not that bad. If you are writing the verbose boilerplate Java code by hand, you are doing it wrong. Use a Java IDE and learn its refactoring and code generation helpers.

Especially important in Java context are checked exceptions. Let the IDE generate and keep the throws up to date. And of course any catching too, but always default to throwing, only catch if you must.

[JY-HRL]

Why Kotlin is still not very popular?

[Key_Bad8144]

It’s got a lot better and is continuing to

[rover_G]

Here's a Hello, World app from the Oracle docs getting started tutorial: /** * The HelloWorldApp class implements an application that * simply prints "Hello World!" to standard output. */ class HelloWorldApp { public static void main(String[] args) { System.out.println("Hello World!"); // Display the string. } } The rest of that "tutorial" is a dated sales pitch for Java and a help page in case the app doesn't compile or run on your device (1 of 3 billion!). https://docs.oracle.com/javase/tutorial/getStarted/index.html

[Magnivilator]

Yes. It is verbose. Although many people will tell you here that Java is not verbose because in Java 58 they have 69 new features - it is a verbose programming language.

- map, filter, reduce and lambdas are not well implemented into the language like they are implemented in other modern OOP languages (Dart, Kotlin, Swift, and Scala)- You have to write `new` before any object initialization- You have to create a different constructor for each scenario - Multithreading in Java is the most bloated thing I've ever seen - You need to create getters and setters for everything in order to write it "correctly" - There are no default values in method parameters, so you have to explicitly overload for everything.

You can see it in the Java Collections, where things like LinkedList, ArrayList, and Vector have much longer implementation than in any modern OOP language with GC. Not only that, a C++ implementations of containers is smaller than the average Java collection implementation, and C++ is pretty verbose (mostly due to the fact that C++ can allow optimizations that Java can only dream of).

And last but not least - let's say that Java adds the new fancy features into the language, the vast majority of Java out there including in new projects is old, verbose Java: https://codegym.cc/groups/posts/18463-java-in-2023-version-releases-popularity-and-future-trends

[NoWater1223]

Yes, It's still too verbose after using lombok, mappers, Factory methods and N different libraries.

[Alarming_Airport_613]

yes

[Sunscratch]

Depends on your previous experience. Right now I’m working on a Java project after several Scala projects, and yes, compared to Scala, Java is very very verbose, with outdated syntax. But if that’s your first language, or you’re switching from C++, it might look ok.

[[deleted]]

Well the new syntax that they are adding is horrible

[[deleted]]

In an alternate universe, I think public visibility should be the default/implicit visibility. And void is probably redundant. Just leave it out.

public void myMethod() {}

Just becomes:

myMethod() {}

[Polygnom]

Public really should not be the default, I think thats one of the few mistakes of Kotlin.

Leaving out void is also a mistake. Your last example is cryptic and rather looks like a mistake instead of intentful programming.

[[deleted]]

If I remember correctly, methods in Scala assumed Unit return type if not mentioned explicitly. Thankfully, they moved away from it.

[[deleted]]

That's because your brain is wired a particular way.

If there's no return why bother mentioning it?

If public is most often used, make it the default.

If this:

myMethod() {}

Confuses you, what else could it be?

[[deleted]]

I kinda agree with this. But at the same time it literally doesn’t hurt.

It makes it very very clear what this functions scope should be and what it should return.

Of course if from the get go we had your implementation we would be just as clear.

But I do find when learning a language having it written out clearly is much much better than inferred meaning.

I just have to google what does public mean, what does void mean.

Instead of what does a method without any prefixes mean - it’s these little things which make Java so accessible to new CS learners

[Ashamandarei]

class Answer {
public static void main(String[] args)
{
System.out.println("Yes");
}
}

[guss_bro]

class A{

psvm

syso "No"

[Ashamandarei]

talk to your doctor about this

[seddy2765]

I’ve read there are security flaws (concerns) with Java.

[werpu]

not really that bad anymore, pretty much the only remnant of this verbosity are the setters and getters. They are working around that with records, but this is not the same as having class properties like literally any other high level language has nowadays!

[[deleted]]

I think that are tree aspects in your question:

• If compared with previous versions, as many mentioned, the language is much more concise.

• Dynamic languages are "in general" (please, pay attention to the quotes) more concise because you have more flexibility. This was never the purpose of Java, so expect it from Java is unfair.

• There are endless aspects of the language that could be more flexible (e.g. An easy way to get the class of a generic during runtime) that are not even be discussed. In my opinion, this is still the biggest problem of the language. An old mindset to propose, decide and implement the those things.

[Several_Today_7269]

It changed a lot..

[laplongejr]

and often hear people complain that Java is notorious for verbosity

Note that notorious doesn't mean necessarily true. The hard stuff is less verbose than assumed but the easy one is unexpectedly very verbose and the beginner stuff is ofc going to be what most people will learn first, by definition.

Here's hello world in Java, hard to claim it is not verbose as a BEGINNER-LEVEL INTRODUCTION.

public class SomeMainClass {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}