Findbugs issues with mutability of Date object in Java

Question

This is more of a follow-up to questions 1 & 2.

As told in the questions the below code

public Date getSomeDate() {
   return someDate;
}

will give you the findbug error issue.

The suggested solution was to duplicate the Date object in both getters and setters like

public Date getSomeDate() {
  return new Date(someDate.getTime());
}

Is this a good approach or are there any alternative ways to this?

Is there any Immutable Date library available in java that can overcome this issue?

you mean immutable right? anyhow, the stated approach is perfect. — Prince John Wesley, Oct 28 '11 at 17:21
@PrinceJohnWesley: thanks and Yes. I have updated the Qs. You means to say its ok to use the Date constructor in all the getters and setter? — ManuPK, Oct 28 '11 at 17:26
As long as you don't expose the calls to external library. you don't need to deep clone(constructor) it because you know what you do. Otherwise always give the difference reference if it is mutable. Try joda time api — Prince John Wesley, Oct 28 '11 at 17:30

score 8 · Answer 1 · edited Dec 24 '13 at 18:34

8

Attention Folks...

besides adapting both the getter and the setter you need to take care about null values:

public Date getSomeDate() {
  if (this.someDate == null) {
    return null;
  }
  return new Date(this.someDate.getTime());
}

public void setSomeDate(final Date someDate) {
  if (someDate == null) {
    this.someDate = null;
  } else{
  this.someDate = new Date(someDate.getTime());
  }
}

edited Dec 24 '13 at 18:34

Community

1
1

answered Nov 05 '13 at 09:19

Martin Bluemel

81
1
1

I hope not. I hope you know for a fact that `someDate` isn’t null and that passing null to the setter is to be considered an error. The defensive copying even gives us the null check for free. – Ole V.V. Feb 26 '20 at 10:15

Dave Newton · Accepted Answer · 2013-11-06T13:35:06.217

6

JodaTime has immutable dates.

Sure, it's okay to use a Date constructor in a getter, why wouldn't it be?

That said, just because FindBugs pegs mutable state as a potential error, it doesn't mean it's intrinsically worth caring about–it depends on how the class is being used. Immutability eliminates one type of bug, which you may or may not need to care a lot about.

edited Nov 06 '13 at 13:35

answered Oct 28 '11 at 17:28

Dave Newton

158,873
26
254
302

Can you give an example of the kind of bug it eliminates? – TomDane May 20 '19 at 20:48
@TomDane ... The kind where something mutates your state out from under you. This isn't unique to `Date`, it's the same as with *anything* that lets you mutate internal state. – Dave Newton May 20 '19 at 21:25

score 0 · Answer 3 · edited Oct 03 '12 at 14:14

0

Wait a minute... by copying the object within the getSomeDate and setSomeDate methods we are not eliminating the security risk since the changed object comes back through the setSomeDate and copies preserve the changed values. It would be necessary to remove setSomeDate in order to solve this kind of security issue, or do not worry at all about it.

edited Oct 03 '12 at 14:14

Marko

20,385
13
48
64

answered Aug 01 '12 at 12:30

Hildeberto Mendonca

133
1
6

2

By returning a copy of the object, we avoid the internal representation being shared - it will help avoiding situations where the calling code (even if it receives this property to a local variable) manipulates this, the bean property will be changed. To state the obvious, setsomeDate cannot be removed as that's the fundamental bean behaviour. – emeralddove Nov 06 '13 at 12:31

score 0 · Answer 4 · answered Oct 28 '11 at 17:56

0

Depending on you use-case you could return someDate.getTime() without wrapping it in a Date.

answered Oct 28 '11 at 17:56

Fredrik LS

1,480
9
15

Findbugs issues with mutability of Date object in Java

4 Answers4

Linked