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