Reputation: 71
SonarQube 5.1 marks a lot of critical issues after reviewing my code. However the class itself and the referenced class in the field is also serializable. The referenced class inherits the serializable interface through a class.
Here is my example
public class A implements Serializable {
private B b; // -> Sonarcube markes this field as not serialzable
}
And the class B is defined as follows
public class B extends C {
....
}
And the class C is defined as follows
public abstract class C extends D {
....
}
And the class D is defined
public abstract class D implements Serializable {
....
}
Running FindBugs on the same project does not see these problems. I am not sure if it is a bug in sonarcube or is my code has some other problems (other fields in the classes C,D or something else)
Does anybody has a clue ?
Upvotes: 7
Views: 21112
Reputation: 13556
Just because some base class is implementing Serializable
does not mean that automatically all derived classes are correctly serializable. Derived classes should define there own serialVersionUid
. Also derived classes could introduce new field whose values might not be serializable.
So unless SonarQube has a hint that the author actually meant the class to be serializable (possibly by restating implements Serializable
or by declaring serialVersionUid
) it is correct for SonarQube to be suspicios about it by Liskovs substition principle.
However the classification as critical could be something that needs discussion. But that is too opinion based for here.
Upvotes: 0
Reputation: 453
It is probably because the binary files are not provided correctly. I had a similar issue with my SonarQube configuration, then I discovered that the classes that implement Serializable
are in different modules and/or in an external library.
Setting correct values for sonar.java.binaries
and sonar.java.libraries
allow SonarQube to locate the binaries and correctly determine whether or not the classes are serializable.
Upvotes: 4