4 ms·

For me that's almost all fields: I try to make just about everything immutable by default. Makes reasoning about concurrency much simpler.

• lmm 12y ago
  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.
  • stevoski 12y ago
    Not quite. eg: public final Date date; date.setTime(1); That's not immutable.
    • lmm 12y ago
      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);
      • cdmckay 12y ago
        Yeah, but with a getter you can make getDate return a copy of the Date object to enforce immutability.
    • cakeface 12y ago
      Yeah, but getDate().setTime(1); works the same way.
      • djur 12y ago
        Not if getDate() returns a copy of the underlying member.
    • mateuszf 12y ago
      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.
      • cdmckay 12y ago
        The Java Date class is not immutable.
        • mateuszf 12y ago
          So you can use a wrapper or Joda time library.
      • brown9-2 12y ago
        A class with mutable fields that a caller can mutate is not immutable.
    • nl 12y ago
      The fact that java.util.Date is terrible is so many ways should go without saying.