"Refactoring is easy, should you need it. If you do not control all the code and it’s usage, you might need to be more careful though."
Bloch's Effective Java is wonderful, but if it has a weakness, it might be that it assumes everyone is writing a library to be used by a lot of developers, many of who are outside your organization.
The example of public fields in data transfer objects is an example of this. Making the fields public is fine if this code is just for you and your team, because you can always refactor it to use accessors later if you need to. But if this code is in a library used by people outside your organization, introducing accessors later without breaking code will be almost impossible.
Public fields like that announce that the object is actually an immutable struct with no internal workings. A need to change it to add computed (or worse, mutable) fields is probably a code smell.
Bloch's Effective Java is wonderful, but if it has a weakness, it might be that it assumes everyone is writing a library to be used by a lot of developers, many of who are outside your organization.
The example of public fields in data transfer objects is an example of this. Making the fields public is fine if this code is just for you and your team, because you can always refactor it to use accessors later if you need to. But if this code is in a library used by people outside your organization, introducing accessors later without breaking code will be almost impossible.