I agree 100%, but the problem is the culture that has grown up around Java. The whole Bean concept encourages violation of encapsulation. IDEs provide automatic generation of accessors and mutators. Many Java programmers have been trained to expect them. At this point, encouraging good OO practice is shouting against the tide.

That being said, I still make my classes immutable unless there is a damn good reason not to.

In Java culture immutable generally means private final member with only a getter and no setter. I would argue that this is good OO design as the purpose of OO design is to protect your interface from future design changes. If you need to change your accessor, you already have one. If the member needs to be mutable at a later date you need only remove the final keyword and potentially add a setter. The interface remains backwards compatible.

I disagree. If you require an accessor to actual internal state, you should rethink your dependencies and reassign some behaviors. Accessors should be rare, mutators almost non-existent.