Does FindBugs EI_EXPOSE_REP error concern only date?

Question

Findbugs reports many EI_EXPOSE_REP and EI_EXPOSE_REP2 errors in my code, every time I write getters and setters as follows:

public Date getDate() { return date; } public void setDate(final Date date) { this.date = date; } 

I understand the meaning of the report, I should not disclose the internal links of my object to the outside world, so that they can not be changed by malicious / offensive code. Correction:

  public Date getDate() { return date == null ? null : date.clone(); } public void setDate(Date date) { this.date = date == null ? null : date.clone(); } 

My question is not here. I am surprised that this report ALWAYS concerns date. Why not all other mutable objects? I think this report also applies to all mutable objects, right?

Should I extend this “good practice” to all my accessors associated with mutable objects?

Give me your advice, thanks

Answer 1

I would probably expect this report to apply to all mutable objects, but I suspect FindBugs is aware of some common criminals.

I usually try to expose the internal state with getters, for example.

 public ArrayList<Trade> getTrades() { return trades; } 

means

• customer may be subject to changes in your trading list
• the customer can modify this list, which you transmitted in good faith.

As such, there are two approaches.

• pass an immutable version of this object (i.e., an object that cannot be changed). In the above scenario, you take a read-only copy of this list and pass it (you can argue that you can just take a simple copy to read and write and pass this in as it will not affect the original object, but it is inconsistent)
• Do not transfer the object (the list of tenders), but rather have an owner object performing operations for this collection for you. This is perhaps the essence of OO-speaking objects to do something for you, rather than request information from them and do it yourself.

Similar arguments apply to setters and constructor arguments.

Note that you can copy many objects when exposed to protect yourself and possibly do a lot of extra work. This is a method that should be used wisely, and it is worthwhile to understand who your customer objects are, and if you can control and / or trust them.

Answer 2

The Date object has setMonth and other setters to manipulate the value, where, since most other variables do not have setter, to change its value (for example, Integer has no setter).

  Case 1 : Date date = obj.getDate(); date.setHours(10); Case 2 : Integer i = obj.getI(); i = 10; 

Finbug only considers case 1 as a security risk.