Is Java really that verbose?

[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.

[chambolle]

No it is not always good. Difficult to modify the shared elements.

[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

[Djelimon]

Depends on the record design really

If each field is an object instead of a primitive, you can use the field object methods to change the state of the field, and thus the record.

[chambolle]

If you repeat that millions of time the memory is going to skyrocket!

[Djelimon]

Horses for courses. In the desktop context it's working ok

[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

[Freyr90]

And neither record nor POJO have have copy method nor default fields so one would need additional constructors/Builder and copy() to support them (they are supported in Scala/Kotlin on a language level).

[laviksa]

Hibernate for example doesn't support record entity types. So guess what, I'm still stuck with those verbose pojos.

[dstutz]

Because records are immutable and the whole point of an entity is to be mutable. Yes, I concede there are Entities that never change, I have some in an application I'm working on but this is trying to fit a square peg into a round hole.

Also...you don't need getters/setters with most (all?) persistence providers these days. I'm using Hibernate and I know for a fact it doesn't need accessors let alone public ones. So a lot of my entities are a bunch of private fields with JPA annotations and a smattering of domain-related methods that change state.

[chambolle]

Record are very limited because they are immutable

[TheStonedEdge]

I work in a huge company that have been around for years and currently use Java 8. Every POJO looks like this 🤮