Re[2]: checkstyle tool to enforce Sun/Oracle code standard on openJdk

Mon Jan 5 19:33:27 UTC 2015

Hi Jonathan,

>  Of course, that does imply that we know what the style should be, which would be a milestone in itself.

I think we should start from what is Code Standard (style) for OpenJdk project, or at least part of it.
Main idea to keep in mind is that style is adjustable to project needs, some changes to style is expected after first implementation of checkstyle configuration for Code Standard, It is even possible that some validations will be switched OFF.
Lets start with something basic.

>  can we configure the IDE to match the recommended style?  

you could end up with style that is reconsiled with used IDEs, we have integration with most IDEs:
http://checkstyle.sourceforge.net/#Related_Tools
I use Eclipse with Checkstyle for very long time.
The only problem could be in Indentation - but we could switch that validation off if it cause conflicts with IDEs settings.
All other validations should not have any conflicts.

>  I would suggest to start by working on specific cleanups, like import-ordering, or spaces around parens,

I stil not not have link to Code Standard to any projects. That will help me verify that all your needs are coverable by Checkstyle.
Some changes to Checkstyle migh be requierd to satisfy your style.

thanks,
Roman Ivanov

Mon, 05 Jan 2015 08:06:14 -0800 от Jonathan Gibbons <jonathan.gibbons at oracle.com>:
> 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
> 
> 

Roman Ivanov