I agree with the article for the most part (except the last snippet where the author reverted to bare, mutable fields), but the point was very badly argued.
I think we really need to consider that sometimes you want a place to hold together data, and some other times you are encoding some behavioral trait, and prior to records Java did not have a way of distinguishing between them.
My rule of thumb is to avoid exposing data in behavioral classes, and prefer immutable patterns for data holders. But sometimes it's not possible to not have setters (e.g. for builders and for JPA entities).
I think we really need to consider that sometimes you want a place to hold together data, and some other times you are encoding some behavioral trait, and prior to records Java did not have a way of distinguishing between them.
My rule of thumb is to avoid exposing data in behavioral classes, and prefer immutable patterns for data holders. But sometimes it's not possible to not have setters (e.g. for builders and for JPA entities).