Sonar analysis of OpenJDK 7 available

[Jonathan Gibbons]

The problem I see here is that different groups within OpenJDK have 
different aspirations and maybe even different conventions. I'm not 
justifying that; I'm simply stating the observation.

We also need to be careful of mass updates.  It would be trivially easy 
to use an IDE to reformat all the JDK source code at the click of a few 
buttons, but that would be a disaster for merging changes from parallel 
lines of development, and might even lead to a religious blood bath 
while determining "the one true style". :-(

In langtools, we're starting with a very low bar, and working up.   For 
example, the dominant style for javac is imports sorted first by group 
(java.*, javax.*, org.*, com.*) and then alphabetically within group. 
So, we've added a target for developers to be able to run CheckStyle to 
check that.

-- Jon


On 11/30/2011 12:43 PM, Martijn Verburg wrote:
> 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
>>