Couldn't agree more. Use public, protected, private fields as they were meant to be used. I only dip into JavaBean anymore if I need a readable but non-writable field.
For me that's almost all fields: I try to make just about everything immutable by default. Makes reasoning about concurrency much simpler.
For immutable you can just use public final fields. I assume GP must be talking about fields that are mutated but only by the object itself, where outside code needs to be able to read but not write.
Not quite. eg:
public final Date date;
date.setTime(1);
That's not immutable.
The bean convention doesn't help you with that one though; if you have private Date date; public Date getDate() {return date;} then people can still do getDate().setTime(1);
Yeah, but with a getter you can make getDate return a copy of the Date object to enforce immutability.
Yeah, but getDate().setTime(1); works the same way.
Not if getDate() returns a copy of the underlying member.
Yep, the thing is that Date is immutable.
I think that this public final immutable rule is ok, but one has to ensure the fields themself are really not modifiable.
The Java Date class is not immutable.
So you can use a wrapper or Joda time library.
A class with mutable fields that a caller can mutate is not immutable.
The fact that java.util.Date is terrible is so many ways should go without saying.