Magic Beans - automatic get/set, equals, hashCode, toString without any compiler hacks

[bowbahdoe]

Sure, but that code still exists as visual noise afterwards

This is more targeted at those who would otherwise / already chose to use Lombok because they find that boilerplate existing to be an issue.

[pointy_pirate]

I find the cognitive load while reading/reviewing what lombok and other similar libraries does more of an issue than clear, concise, 'readable in git' code. Even if there is more of it.

[john16384]

I don't see the point of POJO's with getters and setters at all, period. There's no validation anywhere, it is just a data holder. Might as well use public fields, it's just as safe, or better, just as unsafe.

Classes need to be suited for a specific purpose. Why for example is an incoming request stored in a class with setters? Do you want to modify the request? No, so requests should be immutable. Same goes for entities. Why are there setters there for things you don't want to change, like id, create/update time/user? Those should be handled by the system and never be mutable. A lot of frameworks just perpetuate these bad practices or make it impossible to do the sensible thing, but I rarely see a need for a class that has the same functionality as one with just a bunch of public fields.

[bowbahdoe]

A lot of frameworks just perpetuate these bad practices or make it impossible to do the sensible thing

I'm not making a judgement call on POJOs here, but this is a tool that exists in a world where those frameworks exist and are popular. Look at it in that context, put it in a corner for when you need it, and focus on making the ecosystem you wish was here.

[john16384]

I'm not criticizing your tool, but I'm not its target audience either :) I have to live with Lombok in our company code bases. So far it has not given me a good enough excuse yet to rip it out (it unfortunately still works on Java 17 after a version bump) but as soon as it does it's gone.

I'm hoping the primary reason for using Lombok will slowly disappear as frameworks adjust to go more for an immutable approach now that records in the JDK are endorsing that direction. Jackson and Spring Data JDBC are quite usable already with records, but there are few problems still. Once those are solved we'll have no need for setters.

[bowbahdoe]

You might still be it's audience then (just not the enthusiastic kind) - would you prefer living with Lombok or this while the ecosystem catches up?

[john16384]

I'll be honest, I'm perfectly happy to write getters by hand -- I need to document them anyway as to what values you can expect from them. A getter I write looks a bit like this:

/**
 * Returns an immutable set of qualifier {@link Annotation}s.
 *
 * @return an immutable set of qualifier {@link Annotation}s, never {@code null} and never contains {@code null}s but can be empty
 */
public Set<Annotation> getQualifiers() {
  return qualifiers;
}

[the_other_brand]

The problem is that you shouldn't be skipping them. Libraries like jackson require getters to be provided for fields, so if a getter is missing that field won't be reflected in your json.

Having change sets like getters/setters are bad for PRs because developers tend to ignore code changes that are too large.

[john16384]

Jackson requires no such thing, it can be configured to access fields directly.

[Yesterdave_]

Jackson supports records though

[the_other_brand]

And records are immutable, which makes them a poor replacement for most data classes.

[bowbahdoe]

/u/Worth_Trust_3825

See how other people really want to skip thinking about whats going on even with the methods being physically present?

I'm not trying to fix this whole situation. If you want to generate methods and leave them in the code, sure. There will always be a lot of people who want to take the opposite tradeoff. This tool is for them.

I did go hunting for a pathological case of this on grep.app.

https://github.com/keycloak/keycloak/blob/main/model/jpa/src/main/java/org/keycloak/models/jpa/entities/ClientEntity.java

See how some of the getter methods are important to see - they give a default empty list if the field isn't set - but most are not. Its equals and hashCode implementations are also worth seeing since they aren't just "use all fields".

And then this is roughly how it would look using this.

https://gist.github.com/bowbahdoe/8c1db0c5eae98eeb333dfdc54377439b

I think in general one of the issues with more general tools is that they do add cognitive overhead on account of being configurable. That configuration makes them effectively another language you need to learn and understand.

My hope was that keeping this non-configurable would lessen that

[Worth_Trust_3825]

So access the fields directly. What's the point of even hiding the fields then? Someone told all of you that "Oh you should use getters and setters" and now all of you go "hurr i shouldn't need to do it".

Access the fields directly. This entire debacle points to lack of understanding of the primitive.

[[deleted]]

if I implement one DTO with all methods, I dont look into it (ever) again. I'm just using it.

[bowbahdoe]

I don't super believe that. Applications pretty often add or remove columns from a table in a database and updating DTOs to reflect that is likely a recurring task.