Agreed but immutability can lead to builders and builders lead to lots of code bloat. Plus, from what I've experienced lots of frameworks depend on java bean conventions (i.e. getters/setters for everything).

There's really two missing features of java that could solve 90+% of the use cases for getters/setters.

- Attributes: annotation or keyword based directives for the compiler to generate getters/setters for a given instance variables

- Default + named parameters which would reduce a lot of the pain of multiple constructors and constructors with a tremendous number of parameters.

Instead of attributes that lead to creation of getters/setters, how about the simple notion of private or public access to members? I'm not sure which should be the default, but it sounds like Java programmers would like them private unless otherwise specified. Why add code when all you want is to restrict access?

Lombok (https://projectlombok.org) exists and takes care of the attribute issue you mentioned.

Thats the right answer. Have immutable classes with constructor-injected fields, and getters. In Java Lombok makes this scalable to many members using the builder pattern, and in Kotlin its a non-issue anyway.

You can use setters that return a reference to a new object with the updated says, using some copy and delete mechanism for immutability.