Java plugin 4.0: getters and setters are no longer excluded from Public API metric

313 views
Skip to first unread message

stephan....@qaware.de

unread,
Jul 22, 2016, 6:48:48 AM7/22/16
to SonarQube
Hi,

it seems that the Java plugin version 4.0 no longer excludes getters and setters when measuring the Public API metric.

I'm using SonarQube 5.6 with the Java plugin version 4.0. The following example class is marked with 2 undocumented public APIs:


/**
 * Bean with getter and setter.
 */
public class TestBean {
   
private String someField;

   
public String getSomeField() {
       
return someField;
   
}

   
public void setSomeField(String someField) {
       
this.someField = someField;
   
}
}

This was not the case in older SonarQube and Java plugin versions (e.g. SonarQube 4.5.7 and Java plugin 3.13.1) where setters and getters were ignored.

I guess that the new behavior was introduced with https://jira.sonarsource.com/browse/SONARJAVA-398. As I understand this, it is no longer possilble to configure the exclusion of setters and getters as the corresponding configuration property and the setting in the user interface were removed.

Is it possible to restore the former behavior concerning the Public API metric? In my opinion, commenting getters and setters is (in most cases) superfluous and a waste of time. Furthermore it unnecessarily bloats the code.


Thanks in advance & best regards

Stephan

Michael Gumowski

unread,
Aug 5, 2016, 1:27:23 PM8/5/16
to stephan....@qaware.de, SonarQube
Hello Stephan,

The Undocumented API rule (S1176) ignores setters and getters and should not be impacted by the removal of the distinction between methods, as implied by SONARJAVA-398. Commenting them is not required and the rule should already handle the case properly. When trying to reproduce the issue with version 4.1 of the Java Analyzer, and SQ 5.6, I'm not raising any issue. Am I missing something?

Regarding metrics, we are not going to restore the former behavior. Handling getters and setters as other methods will only have slight impacts on some metrics such as average project complexity, package complexity, and average method complexity of classes. No rule should be impacted.

Regards,

Michael GUMOWSKI | SonarSource
Software Developer @ Language Team
http://sonarsource.com

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/ea204136-ed92-47b0-9677-4c75e1226a67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

stephan....@qaware.de

unread,
Aug 29, 2016, 3:48:45 AM8/29/16
to SonarQube, stephan....@qaware.de
Hello Michael,

thanks for your reply.

The issue seems to be related to my database, that was migrated from SonarQube version 4.5.7. It persists if the project is deleted from the migrated database via the SonarQube user interface and re-analysed. The issue does not occur with a fresh SonarQube 5.6 instance with a clean database.

I have a similar problem with a CSS rule: https://groups.google.com/d/topic/sonarqube/fTaFpTsEgQc/discussion.

Best regards
Stephan
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages