Sonar Java Rule - Autoboxing
jerry...@gmail.com
G. Ann Campbell
Nicolas Peru
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/9d5b9aa8-12d0-451d-a7dd-e306b526c1fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
G. Ann Campbell
Hi Jerry,We are well aware of the pitfalls of autoboxing but if we follow the path you are suggesting it will raise an issue every time there is usage of autoboxing which is fine in most cases.That will be a huge amount of noise : we want to detect flaws, not _potential_ flaws as this is a bad user experience to ask the user to sort out if there is something fishy or not.So while there are some flaws we can detect (and we already have a bunch of rules regarding boxing : https://sonarqube.com/coding_rules#languages=java|q=boxing ) raising an issue for every single case of boxing/unboxing is definitely not a valuable rule as it will be too noisy and we approach things by detecting cases that are known to be problematic (see my previous link). If we do have some cases that you think are always problematic and are not covered by some SonarQube rules then there is a chance we would go to implement a new rule.If you still want to detect boxing cases, without distinction you can still write a custom rule to do so ( http://docs.sonarqube.org/display/PLUG/Writing+Custom+Java+Rules+101 )Cheers,Le ven. 16 sept. 2016 à 14:49, Thome, Jerry <jth...@follett.com> a écrit :Here is a short article which summarizes the potential pitfalls of autoboxing. It’s the best that I’ve seen recently. Auto-boxing and unboxing can become a contentious discussion it seems.
https://dzone.com/articles/autoboxing-and-its-pitfalls-1
We’ve been on the fence about how much we care or not This article above and some other experiences have moved the team to want to fail a build if autoboxing is enabled. I think we can override severity levels in Sonar, so we’d try to elevate it to Blocker to help us fail the build.
Does that help?
Thanks.
Jerry Thome
Development Manager
Tel: (708) 884-7484
Follett Schools Solutions
Development
1391 Corporate Drive
McHenry, IL 60050
jth...@follett.com www.follett.com
From: Nicolas Peru [mailto:nicolas.peru@sonarsource.com]
Sent: Friday, September 16, 2016 2:58 AM
To: Thome, Jerry; ann.ca...@sonarsource.com
Cc: Chwalisz, David; Brost, Allen
Subject: Re: Sonar Java Rule - Autoboxing
Hi Jerry,
Thanks for the example.
Why would you want such examples to raise an issue ? in other words: what would be the suggestion to fix the raised issue ?
Cheers,
Le ven. 16 sept. 2016 à 02:55, Thome, Jerry <jth...@follett.com> a écrit :
Thank you both for your responses. (I switched from my gmail to my work email). Yes, the rule that Nicolas provided below we have used and it’s a good start, but more is desired. Here are a couple examples of what we’d like to see flagged for autoboxing.
==================
Example 1.
==================
Given:
public void RequestLog::setResponseStatus(Integer responseStatus) {
this.responseStatus = responseStatus;
}
And
public int getStatus();
When:
RequestLog requestLog.setResponseStatus(response.getStatus());
Should fail:
The expression of type long is boxed into Long
==================
Example 2.
==================
Given:
public void RequestLog::setDuration(Long duration) {
this.duration = duration;
}
And:
long duration = System.currentTimeMillis() - startTime;
When:
RequestLog requestLog.setDuration(duration);
Should fail:
The expression of type int is boxed into Integer
==================
Example 3.
==================
Given:
Integer pageNumber, Integer pageSize
And:
Query setFirstResult(int startPosition);
When:
Query query; query.setFirstResult((pageNumber - 1) * pageSize);
Should Fail:
(Two occurrences of) The expression of type Integer is unboxed into int
==================
Example 4.
==================
Given:
public Long Clazz::getRawDictionaryCount();
And:
long rawDictionaryCount;
When:
rawDictionaryCount = jobService.getRawDictionaryCount();
Should Fail:
The expression of type Long is unboxed into long
Thank you!
Jerry Thome
Development Manager
Tel: (708) 884-7484
Follett Schools Solutions
Development
1391 Corporate Drive
McHenry, IL 60050
---------- Forwarded message ----------
From: Nicolas Peru <nicola...@sonarsource.com>
Date: Wednesday, September 14, 2016
Subject: Sonar Java Rule - Autoboxing
To: "G. Ann Campbell" <ann.ca...@sonarsource.com>, SonarQube <sona...@googlegroups.com>
Cc: jerry...@gmail.comHi,
The closest rule I can think of is this one : https://sonarqube.com/coding_rules#rule_key=squid%3AS2153
But then the question that come to my mind is : what exactly would you want to detect and, above all, why ?
Cheers,
Le ven. 2 sept. 2016 à 18:15, G. Ann Campbell <ann.ca...@sonarsource.com> a écrit :
Hi Jerry,
Why? Well, probably because no one has made the case for it yet. Would you care to?
:-)
Ann
On Friday, 2 September 2016 12:04:40 UTC-4, jerry...@gmail.com wrote:My teams are going back and forth deciding if we want to detect autoboxing and fail builds. Most IDEs like Eclipse support the detection, but Sonarqube doesn't seem to have an explicit rule to detect autoboxing. Is there a reason why?
Thank you.
--
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/9d5b9aa8-12d0-451d-a7dd-e306b526c1fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--