checkstyle tool to enforce Sun/Oracle code standard on openJdk

Mon Jan 5 16:06:14 UTC 2015

In general, I agree that using Checkstyle on new compilation units 
(files) is a generally good idea.  Of course, that does imply that we 
know what the style should be, which would be a milestone in itself.

As for existing code, you have to tread carefully.  Even applying 
checkstyle to the changes to existing code may be problematic, since it 
is generally considered good manners to mimic the surrounding style when 
making localized edits.  So there is a judgement call of "the bigger the 
chunk of new code, the more acceptable it is to improve the format."

There are some obvious considerations to bear in mind as well:

-- How actively is the code being updated? The more people working in an 
area, the harder the synchronization problems
-- Does the code originate in OpenJDK or is the code a copy of code in 
an upstream project?
-- How prevalent are the violations, meaning, how big would the patches 
be to clean up the code? A patch for a few isolated lines is way more 
acceptable than a white-space cleanup that affects every line
-- How serious are the violations, meaning, how susceptible are the 
violations to merge errors? Edits adding imports in different positions 
can be merged (badly) to produce files with duplicate imports, so 
agreeing on an order of import statements is a good start.

Also, although this discussion has started with checkstyle, I would 
include IDEs. For those of us that use IDEs to work on OpenJDK, can we 
configure the IDE to match the recommended style? For example, for my 
part, I work in NetBeans, and if I'm working on a file with only a 
couple of warning symbols, I'll tend to clean them up where possible, if 
they don't distract too much from what I'm really working on. It's much 
easier to keep a file clear of warnings if the IDEs play along.

Finally, I'd suggest to break the work down into small segments. With 
the warnings cleanup, it was easier to split the work up into blocks 
focussing on different types of warnings in the various components of 
the system, rather than doing all warnings for everything at once.   So, 
in a similar way for style cleanup, I would suggest to start by working 
on specific cleanups, like import-ordering, or spaces around parens,

-- Jon

On 01/03/2015 11:20 PM, Roman Ivanov wrote:
> Hi Jon,
>
> first of all lets deside on last version of "Code Standard", as it might be appeared that changes will be cosmetic.
>
> It might be reasonble to configure Checkstyle to enforce Code Standard on young/new projects or part of the project.
> If project have a lot of backporting and it might be reasonable to enforce Code Standard only in latest code - version 9, and all previous version keep as is.
>
> It also might be reasonable to after config is created, start to use it partly, and slowly increase amount of rules as project have time to resolve style stuff.
>
> The main point - old code/files stay unchanged, new files are created to follow all rules 100%, no backporting problems are guaranteed.
>
> thanks,
> Roman Ivanov
>
>> As attractive as the idea might be, it is not a slam dunk good idea to
>> update the code base to a consistent style.
>>
>> OpenJDK spans multiple versions, and patches get backported between
>> versions. And there are always many projects "in-flight" at any time, at
>> varying stages of development. Doing wholesale style-cleanup can cause
>> undue difficulties when trying to port changesets or merge lines of
>> development.
>>
>> I'm not saying it shouldn't be done; but if it is done, it should be
>> done carefully, in a considered manner, at an appropriate time.   Also,
>> we should consider the relative importance of the fixes.  For example,
>> fixing lint and doclint warnings that might indicate problematic code
>> and comments is more important that fixing errors in whitespace indentation.
>>
>> -- Jon
>>
>> On 12/30/2014 01:07 AM, Roman Ivanov wrote:
>>> Hi OpenJdk engineers,
>>>
>>> I am owner of Checkstyle project -  http://checkstyle.sourceforge.net/index.html   .
>>>    
>>> We had Sun code standard configuration that allow developers
>>> write code in the same approach as authors of Java do.
>>> But a lot of time passed from time that configuration is
>>> introduced, and I am not completely sure that we do complete
>>> and accurate in coverage  of Sun Java Standard.
>>>    
>>> This year we did complete code coverage for Google's style -
>>> http://checkstyle.sourceforge.net/google_style.html
>>>    
>>> Guava team already agreed on fixing problems
>>> and updating style guide to be more precise in some requirements -
>>> https://github.com/google/guava/issues/1891
>>>    
>>> I have an idea to create similar page for Sun/Oracle style -
>>> http://checkstyle.sourceforge.net/sun_style.html
>>>    
>>> Checkstyle already detected a lot of problem in javadoc on openjdk9 (base on change set: 11061:9ade71a206f9 ) -
>>> http://checkstyle.sourceforge.net/reports/javadoc/openjdk9/
>>> That report contains only problems of Javadoc but  it could be as full as report over Guava - http://checkstyle.sourceforge.net/reports/google-style/guava/.
>>>    
>>> Are you interested in such automatic validation of Sun/Oracle Code Standard ?
>>> To let openJDK comply their own code standard :), let automatically validate any contributions to project .
>>>
>>> thanks,
>>> Roman Ivanov