Sonar analysis of OpenJDK 7 available

[Martijn Verburg]

Hi all,

Is this something that the community could help administer? That is,
set up a Wiki page that lists the various warnings and whether the
OpenJDK committers and patch contributors need to adhere to them?

We could add one at a time, starting with the ones that the OpenJDK
committers feel is the most important.

Cheers,
Martijn

On 29 November 2011 02:59, Stuart Marks <stuart.marks at oracle.com> wrote:
> On 11/28/11 3:21 PM, Mario Torre wrote:
>>
>> Il giorno 28/nov/2011, alle ore 19:05, Kelly O'Hair ha scritto:
>>>
>>> On Nov 24, 2011, at 12:36 AM, Roman Kennke wrote:
>>> But I would argue that there are many many more important quality issues
>>> than extra parens in code,
>>> and we should focus on the more important issues.
>>> When you include ALL quality issues like this one in a report, it creates
>>> a HUGE pile of issues that
>>> I consider an unfair representation of the code, and a daunting situation
>>> to deal with.
>>>
>>> My issue is one of priorities, we should focus on the more dangerous
>>> quality issues here,
>>> and not many style issues are high priority in my opinion.
>>
>> I also find return (true) more difficult to read ;) (oh, well, I'm the guy
>> who still asks people to stay
>> within the 80 columns...) but I agree there are better priorities; I also
>> find this kind of results a bit polluting,
>> since they may actually create background noise that will make more
>> important things less obvious.
>>
>> However, all considered, those extremely low priority warnings maybe still
>> good to have around, since they
>> are easy task to be picked by students or people that want to contribute
>> but actually don't have a full view
>> of the platform; in other words they can lower significantly the entry
>> barrier to contribution, which is a good thing
>> imho.
>>
>> I think the best solution is what has been suggested elsewhere in this
>> thread, to have a set of defined rules, or
>> perhaps even more than one set. I would be cool to create a list of "easy"
>> tasks (like other projects like Gnome or
>> LibreOffice have) so that people can start cleaning up the code.
>
> Coincidentally, we've just announced an effort to clean up javac warnings.
> See this recent announcement [1] which I also just forwarded to this list.
> Cleaning up warnings can be one of these "easy" tasks for code cleanup.
>
> A javac warning is sometimes but not always an indication of a quality
> problem. Having lots of noisy warnings tends to obscure the important
> warnings. IMHO cleaning up javac warnings is a higher priority than cleaning
> up code style warnings, since a javac warning is more likely to point out an
> actual bug.
>
> s'marks
>
>
> [1]
> http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-November/000302.html
>