Running blessed-modifier-order on the rest of the JDK

Martin Buchholz martinrb at google.com
Fri Sep 18 19:38:20 UTC 2015


(I'm on both sides of the upstream/downstream divide)

It's a good idea to have a per-directory-tree metadata file that can
provide information about the tree where it is found, like TEST.ROOT but
more general and extensible.  Here at Google we actually have files named
METADATA - this makes it obvious where future metadata needs can be met.
 java/util/METADATA could e.g. explain which files are maintained in Doug
Lea's CVS.

On Fri, Sep 18, 2015 at 12:26 AM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2015-09-17 18:24, Martin Buchholz wrote:
>
>> flush with success, I ran blessed-modifier-order on the entire JDK forest,
>> and it seems to work fine.
>> But we want to leave out code maintained elsewhere.  How to identify that?
>>
>
> As far as I know, the only way to figure out if code is maintained
> elsewhere is to ask someone knowledgable about the code. I've run into this
> problem before, e.g. with regard to warnings (fixing warnings in upstream
> code is much more hassle and probably not a worthwile activity).
>
> Maybe we should adopt some kind of standard, e.g. putting some kind of
> marker file (upstream-source.info?) in directories with upstream source?
> This would allow for easy identification of code maintained elsewhere, and
> might also be a good place to put additional information about the upstream
> project, e.g. a source URL.
>
> Apart from that, I think the job you're doing is great. The JDK code base
> itself really ought to be a paragon in code quality and style, and this
> takes it even further toward that goal.
>
> /Magnus
>
>
>
>> Below are changes inside javadoc, which seem fine to me.
>>
>>   $ hg tcommand hg diff | g '^[+-]  *\*'
>> -         * Access to final protected superclass member from outer class.
>> +         * Access to protected final superclass member from outer class.
>> -     * per a class in order to initialize a final static logger variable,
>> which is then used
>> +     * per a class in order to initialize a static final logger variable,
>> which is then used
>> -     * it is advised that the method is called only once per a class in
>> order to initialize a final static logger variable,
>> +     * it is advised that the method is called only once per a class in
>> order to initialize a static final logger variable,
>> -     * it is advised that the method is called only once per a class in
>> order to initialize a final static logger variable,
>> +     * it is advised that the method is called only once per a class in
>> order to initialize a static final logger variable,
>> -     *     synchronized static method of that class.
>> +     *     static synchronized method of that class.
>> - * abstract protected methods defined in this class need not synchronize
>> + * protected abstract methods defined in this class need not synchronize
>> - *     final static ImageIcon longIcon = new ImageIcon("long.gif");
>> - *     final static ImageIcon shortIcon = new ImageIcon("short.gif");
>> + *     static final ImageIcon longIcon = new ImageIcon("long.gif");
>> + *     static final ImageIcon shortIcon = new ImageIcon("short.gif");
>> - * All attributes should be static private with accessors to simpify
>> change
>> + * All attributes should be private static with accessors to simpify
>> change
>> - * This class holds only final static member variables that are constants
>> + * This class holds only static final member variables that are constants
>> - * inherited static protected members differently when accessed
>> + * inherited protected static members differently when accessed
>>
>> # How big?
>>   $ hg tcommand hg st | grep -w M | wc -l
>> 1952
>>
>
>


More information about the jdk9-dev mailing list