From kumar.x.srinivasan at oracle.com  Fri Apr  1 15:53:00 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 01 Apr 2016 08:53:00 -0700
Subject: RFR: 8073100: [javadoc] Provide an ability to suppress document
	generation for user desired elements.
Message-ID: <56FE995C.40004@oracle.com>

Hello,


Please review [2] as described by [1].

This has been a long standing request from various customers,
the tag was always available under the -javafx tool option,
now the new tag @hidden is for general availability.


Thanks
Kumar


[1] https://bugs.openjdk.java.net/browse/JDK-8073100
[2] http://cr.openjdk.java.net/~ksrini/8073100/webrev.00/

From kumar.x.srinivasan at oracle.com  Fri Apr  8 01:19:33 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 07 Apr 2016 18:19:33 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by javac.
Message-ID: <57070725.1090906@oracle.com>

Hi,

Please review the webrev [1] which fixes [2]. The central theme is, to 
dispatch
all javac related options, off to javac's argument processing, so that 
it is future
proofed and the arguments are processed correctly as required by javac.

Thanks
Kumar

[1] http://cr.openjdk.java.net/~ksrini/8152818/webrev.00/
[2] https://bugs.openjdk.java.net/browse/JDK-8152818

From martinrb at google.com  Fri Apr  8 05:04:25 2016
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 7 Apr 2016 22:04:25 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <57070725.1090906@oracle.com>
References: <57070725.1090906@oracle.com>
Message-ID: <CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>

I'm not really qualified, but here are random comments:

I think the general idea is right - javac and javadoc need the same
kind of support for modules.
I worry that details may be different, e.g. javadoc has diamond
inheritance and pulls in via @{inheritDoc} part of the
"implementation" from module sources.

It would be nice if there was a working sample javadoc command line
for jsr166 CVS.

add SPC before L
+\  -limitmods <module>(,<module>)* Limit the universe of observable modules\n\




On Thu, Apr 7, 2016 at 6:19 PM, Kumar Srinivasan
<kumar.x.srinivasan at oracle.com> wrote:
> Hi,
>
> Please review the webrev [1] which fixes [2]. The central theme is, to
> dispatch
> all javac related options, off to javac's argument processing, so that it is
> future
> proofed and the arguments are processed correctly as required by javac.
>
> Thanks
> Kumar
>
> [1] http://cr.openjdk.java.net/~ksrini/8152818/webrev.00/
> [2] https://bugs.openjdk.java.net/browse/JDK-8152818

From kumar.x.srinivasan at oracle.com  Fri Apr  8 21:44:11 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 08 Apr 2016 14:44:11 -0700
Subject: RFR: 8073100: [javadoc] Provide an ability to suppress document
	generation for user desired elements.
In-Reply-To: <56FE995C.40004@oracle.com>
References: <56FE995C.40004@oracle.com>
Message-ID: <5708262B.6020302@oracle.com>


Hello,

New webrev at:
http://cr.openjdk.java.net/~ksrini/8073100/webrev.01/

Highlights of the changes:
* treatAsPrivate works as before ie. only under -javafx flag.
    * re-instated the tests removed
    * removed @treatAsPrivate synonym.
* simplified the check for the  existence of DocTree.

Thanks

Kumar

> Hello,
>
>
> Please review [2] as described by [1].
>
> This has been a long standing request from various customers,
> the tag was always available under the -javafx tool option,
> now the new tag @hidden is for general availability.
>
>
> Thanks
> Kumar
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8073100
> [2] http://cr.openjdk.java.net/~ksrini/8073100/webrev.00/


From jonathan.gibbons at oracle.com  Mon Apr 11 22:57:35 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 11 Apr 2016 15:57:35 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>
References: <57070725.1090906@oracle.com>
	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>
Message-ID: <570C2BDF.4020202@oracle.com>



On 04/07/2016 10:04 PM, Martin Buchholz wrote:
> I'm not really qualified, but here are random comments:
>
> I think the general idea is right - javac and javadoc need the same
> kind of support for modules.
> I worry that details may be different, e.g. javadoc has diamond
> inheritance and pulls in via @{inheritDoc} part of the
> "implementation" from module sources.

Can you explain this a bit more?   Is this a new problem in JDK 9, 
with/without modules, or
is it a pre-existing problem with @inheritDoc ?

>
> It would be nice if there was a working sample javadoc command line
> for jsr166 CVS.

What would you want to be the goal of such a command line?  Would it be 
to just
document the jsr166 classes, or would you want to generate the JavaSE docs
including the latest jsr166 sources?


>
> add SPC before L
> +\  -limitmods <module>(,<module>)* Limit the universe of observable modules\n\
>
>
>
>
> On Thu, Apr 7, 2016 at 6:19 PM, Kumar Srinivasan
> <kumar.x.srinivasan at oracle.com> wrote:
>> Hi,
>>
>> Please review the webrev [1] which fixes [2]. The central theme is, to
>> dispatch
>> all javac related options, off to javac's argument processing, so that it is
>> future
>> proofed and the arguments are processed correctly as required by javac.
>>
>> Thanks
>> Kumar
>>
>> [1] http://cr.openjdk.java.net/~ksrini/8152818/webrev.00/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8152818


From martinrb at google.com  Mon Apr 11 23:12:53 2016
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 11 Apr 2016 16:12:53 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <570C2BDF.4020202@oracle.com>
References: <57070725.1090906@oracle.com>
	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>
	<570C2BDF.4020202@oracle.com>
Message-ID: <CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>

On Mon, Apr 11, 2016 at 3:57 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
>
>
> On 04/07/2016 10:04 PM, Martin Buchholz wrote:
>>
>> I'm not really qualified, but here are random comments:
>>
>> I think the general idea is right - javac and javadoc need the same
>> kind of support for modules.
>> I worry that details may be different, e.g. javadoc has diamond
>> inheritance and pulls in via @{inheritDoc} part of the
>> "implementation" from module sources.
>
>
> Can you explain this a bit more?   Is this a new problem in JDK 9,
> with/without modules, or
> is it a pre-existing problem with @inheritDoc ?

This is a pre-existing difference between javadoc and javac.  javadoc
has always had diamond inheritance to support @{inheritDoc}.  (Maybe
javac now also has it to support default methods.)

>>
>> It would be nice if there was a working sample javadoc command line
>> for jsr166 CVS.
>
>
> What would you want to be the goal of such a command line?  Would it be to
> just
> document the jsr166 classes, or would you want to generate the JavaSE docs
> including the latest jsr166 sources?

I maintain the javadoc invocations in
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/build.xml?view=markup
that generate
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/
which contains only the javadoc for files in jsr166 CVS.
I'm unsure how we are supposed to generate this in a jigsaw world.
These files are destined to become part of java.base, and they
@{inheritDoc} strings out of java.base sources, but they are also
independent software artifacts.

It doesn't quite fit into jigsaw.  How do you generate javadoc for a
module subset that lives in a separate source tree?

From jonathan.gibbons at oracle.com  Mon Apr 11 23:35:00 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 11 Apr 2016 16:35:00 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>
References: <57070725.1090906@oracle.com>	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>	<570C2BDF.4020202@oracle.com>
	<CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>
Message-ID: <570C34A4.7050408@oracle.com>



On 04/11/2016 04:12 PM, Martin Buchholz wrote:
> On Mon, Apr 11, 2016 at 3:57 PM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>>
>> On 04/07/2016 10:04 PM, Martin Buchholz wrote:
>>> I'm not really qualified, but here are random comments:
>>>
>>> I think the general idea is right - javac and javadoc need the same
>>> kind of support for modules.
>>> I worry that details may be different, e.g. javadoc has diamond
>>> inheritance and pulls in via @{inheritDoc} part of the
>>> "implementation" from module sources.
>>
>> Can you explain this a bit more?   Is this a new problem in JDK 9,
>> with/without modules, or
>> is it a pre-existing problem with @inheritDoc ?
> This is a pre-existing difference between javadoc and javac.  javadoc
> has always had diamond inheritance to support @{inheritDoc}.  (Maybe
> javac now also has it to support default methods.)
>
>>> It would be nice if there was a working sample javadoc command line
>>> for jsr166 CVS.
>>
>> What would you want to be the goal of such a command line?  Would it be to
>> just
>> document the jsr166 classes, or would you want to generate the JavaSE docs
>> including the latest jsr166 sources?
> I maintain the javadoc invocations in
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/build.xml?view=markup
> that generate
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/
> which contains only the javadoc for files in jsr166 CVS.
> I'm unsure how we are supposed to generate this in a jigsaw world.
> These files are destined to become part of java.base, and they
> @{inheritDoc} strings out of java.base sources, but they are also
> independent software artifacts.
>
> It doesn't quite fit into jigsaw.  How do you generate javadoc for a
> module subset that lives in a separate source tree?


Right now, because you want to "{@inheritDoc} strings out of java.base 
sources",
you would have to put much of the jdk/src repo on the module source 
path, with
your repo in front.     I see you're already doing something like that 
in the following
lines:

     <javadoc destdir="${docs.dir}"
              packagenames="none"
              link="${java9.api.url}"
              overview="${src.dir}/intro.html"
              access="${build.javadoc.access}"
              sourcepath="${src.dir}:${jdk9.src.dir}"
              classpath=""
              executable="${javadoc9}">

but now you need to be using -modulesourcepath, which is (regrettably) a 
more
complex option, since javac and javadoc have to be able to isolate the 
module
name in the filename paths.   Obviously, the jdk9/jdk9/jdk repo has its 
source
organized in a modular layout, but to change to using -modulesourcepath, 
your own
${src.dir} would have follow the same general rules, which in the 
simplest case
reduces to having a module name (e.g. java.base) above the sources for the
packages in that module, e.g.    /path/to/java.base/java/util/*.java


From martinrb at google.com  Mon Apr 11 23:53:02 2016
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 11 Apr 2016 16:53:02 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <570C34A4.7050408@oracle.com>
References: <57070725.1090906@oracle.com>
	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>
	<570C2BDF.4020202@oracle.com>
	<CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>
	<570C34A4.7050408@oracle.com>
Message-ID: <CA+kOe099O5aSYx9q64ESyff2vB5v0j+uU_C4rQn+UuQ=1tC5OQ@mail.gmail.com>

I think we can work -modulesourcepath into our build.xml
CVS has zero support for symlinks, but at build time we can create a
skeletal directory
modulesrc/
modulesrc/java.base -> ${src.dir}
or if necessary copy the entire tree when running javadoc.

We're reluctant to reorganize our src/main directory because it messes
with CVS history.

What I'm afraid of is spending several development cycles of you
trying to get us what we want and it not quite working, when it would
be faster for you to test directly on a jsr166 CVS checkout.  Create a
javadoc9 command line that recreates our
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/
and jsr166 maintainers can do the rest.

On Mon, Apr 11, 2016 at 4:35 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
>
>
> On 04/11/2016 04:12 PM, Martin Buchholz wrote:
>>
>> On Mon, Apr 11, 2016 at 3:57 PM, Jonathan Gibbons
>> <jonathan.gibbons at oracle.com> wrote:
>>>
>>>
>>> On 04/07/2016 10:04 PM, Martin Buchholz wrote:
>>>>
>>>> I'm not really qualified, but here are random comments:
>>>>
>>>> I think the general idea is right - javac and javadoc need the same
>>>> kind of support for modules.
>>>> I worry that details may be different, e.g. javadoc has diamond
>>>> inheritance and pulls in via @{inheritDoc} part of the
>>>> "implementation" from module sources.
>>>
>>>
>>> Can you explain this a bit more?   Is this a new problem in JDK 9,
>>> with/without modules, or
>>> is it a pre-existing problem with @inheritDoc ?
>>
>> This is a pre-existing difference between javadoc and javac.  javadoc
>> has always had diamond inheritance to support @{inheritDoc}.  (Maybe
>> javac now also has it to support default methods.)
>>
>>>> It would be nice if there was a working sample javadoc command line
>>>> for jsr166 CVS.
>>>
>>>
>>> What would you want to be the goal of such a command line?  Would it be
>>> to
>>> just
>>> document the jsr166 classes, or would you want to generate the JavaSE
>>> docs
>>> including the latest jsr166 sources?
>>
>> I maintain the javadoc invocations in
>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/build.xml?view=markup
>> that generate
>> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/
>> which contains only the javadoc for files in jsr166 CVS.
>> I'm unsure how we are supposed to generate this in a jigsaw world.
>> These files are destined to become part of java.base, and they
>> @{inheritDoc} strings out of java.base sources, but they are also
>> independent software artifacts.
>>
>> It doesn't quite fit into jigsaw.  How do you generate javadoc for a
>> module subset that lives in a separate source tree?
>
>
>
> Right now, because you want to "{@inheritDoc} strings out of java.base
> sources",
> you would have to put much of the jdk/src repo on the module source path,
> with
> your repo in front.     I see you're already doing something like that in
> the following
> lines:
>
>     <javadoc destdir="${docs.dir}"
>              packagenames="none"
>              link="${java9.api.url}"
>              overview="${src.dir}/intro.html"
>              access="${build.javadoc.access}"
>              sourcepath="${src.dir}:${jdk9.src.dir}"
>              classpath=""
>              executable="${javadoc9}">
>
> but now you need to be using -modulesourcepath, which is (regrettably) a
> more
> complex option, since javac and javadoc have to be able to isolate the
> module
> name in the filename paths.   Obviously, the jdk9/jdk9/jdk repo has its
> source
> organized in a modular layout, but to change to using -modulesourcepath,
> your own
> ${src.dir} would have follow the same general rules, which in the simplest
> case
> reduces to having a module name (e.g. java.base) above the sources for the
> packages in that module, e.g.    /path/to/java.base/java/util/*.java
>

From kumar.x.srinivasan at oracle.com  Fri Apr 15 15:17:05 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 15 Apr 2016 08:17:05 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <CA+kOe099O5aSYx9q64ESyff2vB5v0j+uU_C4rQn+UuQ=1tC5OQ@mail.gmail.com>
References: <57070725.1090906@oracle.com>
	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>
	<570C2BDF.4020202@oracle.com>
	<CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>
	<570C34A4.7050408@oracle.com>
	<CA+kOe099O5aSYx9q64ESyff2vB5v0j+uU_C4rQn+UuQ=1tC5OQ@mail.gmail.com>
Message-ID: <571105F1.1010808@oracle.com>


Martin,

The bug  8152818 was pushed last night, below is a recipe
to build  jsr166's API doc.  Please note, this is not an  optimal
solution, and also encountered a javac issue JDK-8154152,
also we are in discussion on a simpler method to address your
jsr166  and other similar use cases that have been brought to
our attention. Please check if the output is what you expect, I
did not have time to go through the output.

Thanks
Kumar

JDKDIR=<jdk_forest_dir>
JSR166_SRC=./jsr166/src/java.base
JDK_SRC=$JDKDIR/jdk/src/*/share/classes
CORBA_SRC=$JDKDIR/corba/src/*/share/classes
LT_SRC=$JDKDIR/langtools/src/*/share/classes
PLAT_SRC=$JDKDIR/jdk/src/*/unix/classes
GEN_SRC=$JDKDIR/build/linux-x86_64-normal-server-release/support/gensrc/*
JAVA_HOME=$JDKDIR/build/linux-x86_64-normal-server-release/images/jdk

JDK9_SRC=$JDK_SRC:$CORBA_SRC:$LT_SRC:$PLAT_SRC:$GEN_SRC

$JAVA_HOME/bin/javadoc -d  javadoc-out \
   -tag 'apiNote:a:API Note:' \
   -tag 'implSpec:a:Implementation Requirements:' \
   -tag 'implNote:a:Implementation Note:' \
   -tag 'jvms:a:See <cite> The Java&trade; Virtual Machine 
Specification</cite>:' \
   -tag 'jls:a:See <cite> The Java&trade; Language Specification</cite>:' \
   -modulesourcepath $JSR166_SRC:$JDK9_SRC \
   java.util \
   java.util.concurrent \
   java.util.concurrent.locks \
   java.util.concurrent.atomic






> I think we can work -modulesourcepath into our build.xml
> CVS has zero support for symlinks, but at build time we can create a
> skeletal directory
> modulesrc/
> modulesrc/java.base -> ${src.dir}
> or if necessary copy the entire tree when running javadoc.
>
> We're reluctant to reorganize our src/main directory because it messes
> with CVS history.
>
> What I'm afraid of is spending several development cycles of you
> trying to get us what we want and it not quite working, when it would
> be faster for you to test directly on a jsr166 CVS checkout.  Create a
> javadoc9 command line that recreates our
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/
> and jsr166 maintainers can do the rest.
>
> On Mon, Apr 11, 2016 at 4:35 PM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>>
>> On 04/11/2016 04:12 PM, Martin Buchholz wrote:
>>> On Mon, Apr 11, 2016 at 3:57 PM, Jonathan Gibbons
>>> <jonathan.gibbons at oracle.com> wrote:
>>>>
>>>> On 04/07/2016 10:04 PM, Martin Buchholz wrote:
>>>>> I'm not really qualified, but here are random comments:
>>>>>
>>>>> I think the general idea is right - javac and javadoc need the same
>>>>> kind of support for modules.
>>>>> I worry that details may be different, e.g. javadoc has diamond
>>>>> inheritance and pulls in via @{inheritDoc} part of the
>>>>> "implementation" from module sources.
>>>>
>>>> Can you explain this a bit more?   Is this a new problem in JDK 9,
>>>> with/without modules, or
>>>> is it a pre-existing problem with @inheritDoc ?
>>> This is a pre-existing difference between javadoc and javac.  javadoc
>>> has always had diamond inheritance to support @{inheritDoc}.  (Maybe
>>> javac now also has it to support default methods.)
>>>
>>>>> It would be nice if there was a working sample javadoc command line
>>>>> for jsr166 CVS.
>>>>
>>>> What would you want to be the goal of such a command line?  Would it be
>>>> to
>>>> just
>>>> document the jsr166 classes, or would you want to generate the JavaSE
>>>> docs
>>>> including the latest jsr166 sources?
>>> I maintain the javadoc invocations in
>>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/build.xml?view=markup
>>> that generate
>>> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/
>>> which contains only the javadoc for files in jsr166 CVS.
>>> I'm unsure how we are supposed to generate this in a jigsaw world.
>>> These files are destined to become part of java.base, and they
>>> @{inheritDoc} strings out of java.base sources, but they are also
>>> independent software artifacts.
>>>
>>> It doesn't quite fit into jigsaw.  How do you generate javadoc for a
>>> module subset that lives in a separate source tree?
>>
>>
>> Right now, because you want to "{@inheritDoc} strings out of java.base
>> sources",
>> you would have to put much of the jdk/src repo on the module source path,
>> with
>> your repo in front.     I see you're already doing something like that in
>> the following
>> lines:
>>
>>      <javadoc destdir="${docs.dir}"
>>               packagenames="none"
>>               link="${java9.api.url}"
>>               overview="${src.dir}/intro.html"
>>               access="${build.javadoc.access}"
>>               sourcepath="${src.dir}:${jdk9.src.dir}"
>>               classpath=""
>>               executable="${javadoc9}">
>>
>> but now you need to be using -modulesourcepath, which is (regrettably) a
>> more
>> complex option, since javac and javadoc have to be able to isolate the
>> module
>> name in the filename paths.   Obviously, the jdk9/jdk9/jdk repo has its
>> source
>> organized in a modular layout, but to change to using -modulesourcepath,
>> your own
>> ${src.dir} would have follow the same general rules, which in the simplest
>> case
>> reduces to having a module name (e.g. java.base) above the sources for the
>> packages in that module, e.g.    /path/to/java.base/java/util/*.java
>>


From martinrb at google.com  Sat Apr 16 22:32:10 2016
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 16 Apr 2016 15:32:10 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <571105F1.1010808@oracle.com>
References: <57070725.1090906@oracle.com>
	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>
	<570C2BDF.4020202@oracle.com>
	<CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>
	<570C34A4.7050408@oracle.com>
	<CA+kOe099O5aSYx9q64ESyff2vB5v0j+uU_C4rQn+UuQ=1tC5OQ@mail.gmail.com>
	<571105F1.1010808@oracle.com>
Message-ID: <CA+kOe0_06Teuzc+G3OCCCERXf4RxhtxFqE6-35xqszhZyR_Dxw@mail.gmail.com>

On Fri, Apr 15, 2016 at 8:17 AM, Kumar Srinivasan
<kumar.x.srinivasan at oracle.com> wrote:
>
> Martin,
>
> The bug  8152818 was pushed last night, below is a recipe
> to build  jsr166's API doc.  Please note, this is not an  optimal
> solution, and also encountered a javac issue JDK-8154152,
> also we are in discussion on a simpler method to address your
> jsr166  and other similar use cases that have been brought to
> our attention. Please check if the output is what you expect, I
> did not have time to go through the output.
>
> Thanks
> Kumar
>
> JDKDIR=<jdk_forest_dir>
> JSR166_SRC=./jsr166/src/java.base
> JDK_SRC=$JDKDIR/jdk/src/*/share/classes
> CORBA_SRC=$JDKDIR/corba/src/*/share/classes
> LT_SRC=$JDKDIR/langtools/src/*/share/classes
> PLAT_SRC=$JDKDIR/jdk/src/*/unix/classes
> GEN_SRC=$JDKDIR/build/linux-x86_64-normal-server-release/support/gensrc/*
> JAVA_HOME=$JDKDIR/build/linux-x86_64-normal-server-release/images/jdk
>
> JDK9_SRC=$JDK_SRC:$CORBA_SRC:$LT_SRC:$PLAT_SRC:$GEN_SRC
>
> $JAVA_HOME/bin/javadoc -d  javadoc-out \
>   -tag 'apiNote:a:API Note:' \
>   -tag 'implSpec:a:Implementation Requirements:' \
>   -tag 'implNote:a:Implementation Note:' \
>   -tag 'jvms:a:See <cite> The Java&trade; Virtual Machine
> Specification</cite>:' \
>   -tag 'jls:a:See <cite> The Java&trade; Language Specification</cite>:' \
>   -modulesourcepath $JSR166_SRC:$JDK9_SRC \
>   java.util \
>   java.util.concurrent \
>   java.util.concurrent.locks \
>   java.util.concurrent.atomic

I tried and failed to get any variant of the above to produce any
output at all :(
But I didn't try that hard, because the above appears to try to
produce docs for all of java.util, and we are only interested in a
small subset of java.util.  So we have traditionally provided javadoc
an explicit list of files as input, and want to continue doing that.

I tried a bunch of experiments; details in subsequent messages.

From martinrb at google.com  Sat Apr 16 22:39:42 2016
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 16 Apr 2016 15:39:42 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <CA+kOe0_06Teuzc+G3OCCCERXf4RxhtxFqE6-35xqszhZyR_Dxw@mail.gmail.com>
References: <57070725.1090906@oracle.com>
	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>
	<570C2BDF.4020202@oracle.com>
	<CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>
	<570C34A4.7050408@oracle.com>
	<CA+kOe099O5aSYx9q64ESyff2vB5v0j+uU_C4rQn+UuQ=1tC5OQ@mail.gmail.com>
	<571105F1.1010808@oracle.com>
	<CA+kOe0_06Teuzc+G3OCCCERXf4RxhtxFqE6-35xqszhZyR_Dxw@mail.gmail.com>
Message-ID: <CA+kOe0885gV8ACtkUYR7y2bhEje+xVe1qTVDSm=s1qC-sXexuw@mail.gmail.com>

Below is a script that successfully processes all of the jsr166 source
files, but ignores JDK sources and so all of the {@inheritDoc} are
left blank, which is a regression.

I couldn't find any way to get javadoc to warn me if the {@inheritDoc}
snippets could not be filled in (sort of a "linker error").  You would
think -Xdoclint:all would do that.  Seems like a BUG.

#!/bin/bash
set -eu
JDKSRC=/home/martin/ws/jdk9-dev
JDK=$JDKSRC/build/linux-x86_64-normal-server-release/images/jdk
DIR=bug1
rm -rf $DIR
cvs -Q -d ':pserver:anonymous:@gee.cs.oswego.edu/home/jsr166/jsr166'
checkout -d $DIR jsr166/src/main
cd $DIR

find -name '*.java' |
xargs perl -0777 -pi -e 's~sun\.(reflect|misc)~jdk.internal.$1~g'

exec $JDK/bin/javadoc \
  -d docs \
  -Xdoclint:all \
  -Xmodule:java.base \
  -Xdocrootparent http://docs.oracle.com/javase/9/docs \
  -tag 'jls:a:See <cite> The Java&trade; Language Specification</cite>:' \
  -tag 'implSpec:a:Implementation Requirements:' \
  -tag 'implNote:a:Implementation Note:' \
  $(find java -name '*.java')

From martinrb at google.com  Sat Apr 16 22:45:46 2016
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 16 Apr 2016 15:45:46 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <CA+kOe0885gV8ACtkUYR7y2bhEje+xVe1qTVDSm=s1qC-sXexuw@mail.gmail.com>
References: <57070725.1090906@oracle.com>
	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>
	<570C2BDF.4020202@oracle.com>
	<CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>
	<570C34A4.7050408@oracle.com>
	<CA+kOe099O5aSYx9q64ESyff2vB5v0j+uU_C4rQn+UuQ=1tC5OQ@mail.gmail.com>
	<571105F1.1010808@oracle.com>
	<CA+kOe0_06Teuzc+G3OCCCERXf4RxhtxFqE6-35xqszhZyR_Dxw@mail.gmail.com>
	<CA+kOe0885gV8ACtkUYR7y2bhEje+xVe1qTVDSm=s1qC-sXexuw@mail.gmail.com>
Message-ID: <CA+kOe09o3ZV2H7B9amg0Noc9uWsFnLJx8NnKRuNRuGwuWC4=-w@mail.gmail.com>

Here's a variant where I try adding -modulesearchpath pointing at the
jdk sources.

It fails with the error

java/util/PriorityQueue.java:26: error: unnamed package is not allowed
in named modules
package java.util;
^

... but that's nonsensical - this is not an unnamed package.  That's
the package statement right there!
Seems like a BUG.

#!/bin/bash
set -eu
JDKSRC=/home/martin/ws/jdk9-dev
JDK=$JDKSRC/build/linux-x86_64-normal-server-release/images/jdk
DIR=bug2
rm -rf $DIR
cvs -Q -d ':pserver:anonymous:@gee.cs.oswego.edu/home/jsr166/jsr166'
checkout -d $DIR jsr166/src/main
cd $DIR

find -name '*.java' |
xargs perl -0777 -pi -e 's~sun\.(reflect|misc)~jdk.internal.$1~g'

exec $JDK/bin/javadoc \
  -d docs \
  -Xdoclint:all \
  -Xmodule:java.base \
  -modulesourcepath "$JDKSRC/jdk/src/java.base/share/classes" \
  -Xdocrootparent http://docs.oracle.com/javase/9/docs \
  -tag 'jls:a:See <cite> The Java&trade; Language Specification</cite>:' \
  -tag 'implSpec:a:Implementation Requirements:' \
  -tag 'implNote:a:Implementation Note:' \
  $(find java -name '*.java')

From martinrb at google.com  Sat Apr 16 22:51:07 2016
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 16 Apr 2016 15:51:07 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <CA+kOe09o3ZV2H7B9amg0Noc9uWsFnLJx8NnKRuNRuGwuWC4=-w@mail.gmail.com>
References: <57070725.1090906@oracle.com>
	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>
	<570C2BDF.4020202@oracle.com>
	<CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>
	<570C34A4.7050408@oracle.com>
	<CA+kOe099O5aSYx9q64ESyff2vB5v0j+uU_C4rQn+UuQ=1tC5OQ@mail.gmail.com>
	<571105F1.1010808@oracle.com>
	<CA+kOe0_06Teuzc+G3OCCCERXf4RxhtxFqE6-35xqszhZyR_Dxw@mail.gmail.com>
	<CA+kOe0885gV8ACtkUYR7y2bhEje+xVe1qTVDSm=s1qC-sXexuw@mail.gmail.com>
	<CA+kOe09o3ZV2H7B9amg0Noc9uWsFnLJx8NnKRuNRuGwuWC4=-w@mail.gmail.com>
Message-ID: <CA+kOe0_gtw0Z1hRCzHAvOY_77hoHwiJD5Xtm0Pn97=E6twCJHw@mail.gmail.com>

If I try to pull in @inheritDoc sources using -sourcepath instead of
-modulesourcepath, I get

java/util/ArrayPrefixHelpers.java:7: error: illegal combination of
-Xmodule and module-info on classpath
package java.util;
^
java.lang.AssertionError
at com.sun.tools.javac.util.Assert.error(jdk.compiler at 9-internal/Assert.java:155)
at com.sun.tools.javac.util.Assert.checkNull(jdk.compiler at 9-internal/Assert.java:54)
at com.sun.tools.javac.code.Symtab.enterModule(jdk.compiler at 9-internal/Symtab.java:755)
at com.sun.tools.javac.comp.Modules.enterModule(jdk.compiler at 9-internal/Modules.java:257)
at com.sun.tools.javac.comp.Modules.enterModules(jdk.compiler at 9-internal/Modules.java:235)
at com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-internal/Modules.java:203)
at com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-internal/JavaCompiler.java:816)
at com.sun.tools.javac.main.JavaCompiler.readSourceFile(jdk.compiler at 9-internal/JavaCompiler.java:778)
at com.sun.tools.javac.main.JavaCompiler.access$100(jdk.compiler at 9-internal/JavaCompiler.java:97)
at com.sun.tools.javac.main.JavaCompiler$1.complete(jdk.compiler at 9-internal/JavaCompiler.java:339)
at com.sun.tools.javac.code.ClassFinder.fillIn(jdk.compiler at 9-internal/ClassFinder.java:362)
at com.sun.tools.javac.code.ModuleFinder.lambda$findSingleModule$0(jdk.compiler at 9-internal/ModuleFinder.java:206)
at com.sun.tools.javac.code.Symbol.complete(jdk.compiler at 9-internal/Symbol.java:602)
at com.sun.tools.javac.comp.Modules.setCompilationUnitModules(jdk.compiler at 9-internal/Modules.java:361)
at com.sun.tools.javac.comp.Modules.enter(jdk.compiler at 9-internal/Modules.java:205)
at jdk.javadoc.internal.tool.JavadocTool.getEnvironment(jdk.javadoc at 9-internal/JavadocTool.java:190)
at jdk.javadoc.internal.tool.Start.parseAndExecute(jdk.javadoc at 9-internal/Start.java:403)
at jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-internal/Start.java:276)
at jdk.javadoc.internal.tool.Start.begin(jdk.javadoc at 9-internal/Start.java:222)
at jdk.javadoc.internal.tool.Main.execute(jdk.javadoc at 9-internal/Main.java:70)
at jdk.javadoc.internal.tool.Main.main(jdk.javadoc at 9-internal/Main.java:52)

It's not completely clear to me that the combination should be a fatal error.

The module-info is found on the sourcepath, not the classpath; that
seems like a BUG in the message text.

Of course the AssertionError is also a BUG.

#!/bin/bash
set -eu
JDKSRC=/home/martin/ws/jdk9-dev
JDK=$JDKSRC/build/linux-x86_64-normal-server-release/images/jdk
DIR=bug3
rm -rf $DIR
cvs -Q -d ':pserver:anonymous:@gee.cs.oswego.edu/home/jsr166/jsr166'
checkout -d $DIR jsr166/src/main
cd $DIR

find -name '*.java' |
xargs perl -0777 -pi -e 's~sun\.(reflect|misc)~jdk.internal.$1~g'

exec $JDK/bin/javadoc \
  -d docs \
  -Xdoclint:all \
  -Xmodule:java.base \
  -sourcepath "$JDKSRC/jdk/src/java.base/share/classes" \
  -Xdocrootparent http://docs.oracle.com/javase/9/docs \
  -tag 'jls:a:See <cite> The Java&trade; Language Specification</cite>:' \
  -tag 'implSpec:a:Implementation Requirements:' \
  -tag 'implNote:a:Implementation Note:' \
  $(find java -name '*.java')

From martinrb at google.com  Sat Apr 16 23:12:58 2016
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 16 Apr 2016 16:12:58 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <CA+kOe0_gtw0Z1hRCzHAvOY_77hoHwiJD5Xtm0Pn97=E6twCJHw@mail.gmail.com>
References: <57070725.1090906@oracle.com>
	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>
	<570C2BDF.4020202@oracle.com>
	<CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>
	<570C34A4.7050408@oracle.com>
	<CA+kOe099O5aSYx9q64ESyff2vB5v0j+uU_C4rQn+UuQ=1tC5OQ@mail.gmail.com>
	<571105F1.1010808@oracle.com>
	<CA+kOe0_06Teuzc+G3OCCCERXf4RxhtxFqE6-35xqszhZyR_Dxw@mail.gmail.com>
	<CA+kOe0885gV8ACtkUYR7y2bhEje+xVe1qTVDSm=s1qC-sXexuw@mail.gmail.com>
	<CA+kOe09o3ZV2H7B9amg0Noc9uWsFnLJx8NnKRuNRuGwuWC4=-w@mail.gmail.com>
	<CA+kOe0_gtw0Z1hRCzHAvOY_77hoHwiJD5Xtm0Pn97=E6twCJHw@mail.gmail.com>
Message-ID: <CA+kOe08kOjZn3jjUdtugXW4BtT4jfhUApmTC0=SDvkZ7XJsyQg@mail.gmail.com>

A final and successful (but disappointing) experiment.

Copying the JDK sources, deleting the module-info.java file and using
the traditional -sourcepath flag with that brings success.
It's disappointing because it's clearly an ugly hack and retreating to
a pre-jigsaw world (but -Xmodule:java.base works!)

We get annoying warnings from files that are not involved in this compilation,

sourcepath/java/util/GregorianCalendar.java:3231: warning: no @throws
for java.lang.ClassNotFoundException
    private void readObject(ObjectInputStream stream)

but that seems like a pre-existing BUG (jdk8 has it too)
(why, oh why, is javadoc wasting its time analyzing GregorianCalendar.java?)

#!/bin/bash
set -eu
JDKSRC=/home/martin/ws/jdk9-dev
JDK=$JDKSRC/build/linux-x86_64-normal-server-release/images/jdk
DIR=bug4
rm -rf $DIR
cvs -Q -d ':pserver:anonymous:@gee.cs.oswego.edu/home/jsr166/jsr166'
checkout -d $DIR jsr166/src/main
cd $DIR

find -name '*.java' |
xargs perl -0777 -pi -e 's~sun\.(reflect|misc)~jdk.internal.$1~g'

rsync -a "$JDKSRC/jdk/src/java.base/share/classes/" sourcepath/
rm sourcepath/module-info.java

exec $JDK/bin/javadoc \
  -d docs \
  -Xdoclint:all \
  -Xmodule:java.base \
  -sourcepath "sourcepath" \
  -Xdocrootparent http://docs.oracle.com/javase/9/docs \
  -tag 'jls:a:See <cite> The Java&trade; Language Specification</cite>:' \
  -tag 'implSpec:a:Implementation Requirements:' \
  -tag 'implNote:a:Implementation Note:' \
  $(find java -name '*.java')

From martinrb at google.com  Sat Apr 16 23:33:40 2016
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 16 Apr 2016 16:33:40 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <CA+kOe08kOjZn3jjUdtugXW4BtT4jfhUApmTC0=SDvkZ7XJsyQg@mail.gmail.com>
References: <57070725.1090906@oracle.com>
	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>
	<570C2BDF.4020202@oracle.com>
	<CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>
	<570C34A4.7050408@oracle.com>
	<CA+kOe099O5aSYx9q64ESyff2vB5v0j+uU_C4rQn+UuQ=1tC5OQ@mail.gmail.com>
	<571105F1.1010808@oracle.com>
	<CA+kOe0_06Teuzc+G3OCCCERXf4RxhtxFqE6-35xqszhZyR_Dxw@mail.gmail.com>
	<CA+kOe0885gV8ACtkUYR7y2bhEje+xVe1qTVDSm=s1qC-sXexuw@mail.gmail.com>
	<CA+kOe09o3ZV2H7B9amg0Noc9uWsFnLJx8NnKRuNRuGwuWC4=-w@mail.gmail.com>
	<CA+kOe0_gtw0Z1hRCzHAvOY_77hoHwiJD5Xtm0Pn97=E6twCJHw@mail.gmail.com>
	<CA+kOe08kOjZn3jjUdtugXW4BtT4jfhUApmTC0=SDvkZ7XJsyQg@mail.gmail.com>
Message-ID: <CA+kOe0-gMkRGvQpQn2B3BZxxitgT43n9aC0dBU3OYV+pgrivBw@mail.gmail.com>

One more non-gripe!
If I leave the references to sun.misc.Unsafe (instead of the
jdk.internal variant) I get:

java/util/concurrent/atomic/AtomicLong.java:28: error: package
sun.misc does not exist
    private static final sun.misc.Unsafe U = sun.misc.Unsafe.getUnsafe();

But I notice that the architected
  -XaddReads:java.base=jdk.unsupported \
succeeds in removing it.

#!/bin/bash
set -eu
JDKSRC=/home/martin/ws/jdk9-dev
JDK=$JDKSRC/build/linux-x86_64-normal-server-release/images/jdk
DIR=bug5
rm -rf $DIR
cvs -Q -d ':pserver:anonymous:@gee.cs.oswego.edu/home/jsr166/jsr166'
checkout -d $DIR jsr166/src/main
cd $DIR

find -name '*.java' |
xargs perl -0777 -pi -e 's~sun\.(reflect)~jdk.internal.$1~g'

rsync -a "$JDKSRC/jdk/src/java.base/share/classes/" sourcepath/
rm sourcepath/module-info.java

exec $JDK/bin/javadoc \
  -d docs \
  -Xdoclint:all \
  -Xmodule:java.base \
  -XaddReads:java.base=jdk.unsupported \
  -sourcepath "sourcepath" \
  -Xdocrootparent http://docs.oracle.com/javase/9/docs \
  -tag 'jls:a:See <cite> The Java&trade; Language Specification</cite>:' \
  -tag 'implSpec:a:Implementation Requirements:' \
  -tag 'implNote:a:Implementation Note:' \
  $(find java -name '*.java')

From jonathan.gibbons at oracle.com  Mon Apr 18 15:02:48 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 18 Apr 2016 08:02:48 -0700
Subject: Javadoc custom Taglets
In-Reply-To: <op.yf18zhbnkdkhrr@desktop-2khsk44.dynamic.ziggo.nl>
References: <op.yf18zhbnkdkhrr@desktop-2khsk44.dynamic.ziggo.nl>
Message-ID: <5714F718.1080304@oracle.com>

FYI

On 04/17/2016 04:03 AM, Robert Scholte wrote:
> Hi,
>
> in preparation of the DevoxxFr talk about Maven and Java9 by Herv? 
> Boutemy and Arnaud H?ritier I noticed some issues with custom taglets 
> when generation Javadoc reports.
>
> For the developers of Maven plugins we have a set of Annotations or 
> DocletTags[1] to generate the plugin descriptor.
> The taglets are based on com.sun.tools.doclets.Taglet, but when trying 
> to run this with Java 9-ea+113 I get the following exception.
>
> Caused by: org.apache.maven.plugin.MojoExecutionException: An error 
> has occurred in JavaDocs report generation:
> Exit code: 1 - javadoc: error - Error - Exception 
> java.lang.ClassCastException thrown while trying to register Taglet 
> org.apache.maven.tools.plugin.javadoc.MojoAggregatorTypeTaglet...
>
> What's the preferred way to write custom Taglets when using Java9 and 
> will this also work with older versions of Java?
>
> thanks,
> Robert
>
> [1] 
> https://maven.apache.org/components/plugin-tools/maven-plugin-tools-javadoc/



From rfscholte at apache.org  Mon Apr 18 16:52:42 2016
From: rfscholte at apache.org (Robert Scholte)
Date: Mon, 18 Apr 2016 18:52:42 +0200
Subject: Custom Taglets
Message-ID: <op.yf4jt415kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>

Hi,

in preparation of the DevoxxFr talk about Maven and Java9 by Herv? Boutemy  
and Arnaud H?ritier I noticed some issues with custom taglets when  
generation Javadoc reports.

For the developers of Maven plugins we have a set of Annotations or  
DocletTags[1] to generate the plugin descriptor.
The taglets are based on com.sun.tools.doclets.Taglet, but when trying to  
run this with Java 9-ea+113 I get the following exception.

Caused by: org.apache.maven.plugin.MojoExecutionException: An error has  
occurred in JavaDocs report generation:
Exit code: 1 - javadoc: error - Error - Exception  
java.lang.ClassCastException thrown while trying to register Taglet  
org.apache.maven.tools.plugin.javadoc.MojoAggregatorTypeTaglet...

What's the preferred way to write custom Taglets when using Java9 and will  
this also work with older versions of Java?

thanks,
Robert

[1]  
https://maven.apache.org/components/plugin-tools/maven-plugin-tools-javadoc/

From jonathan.gibbons at oracle.com  Mon Apr 18 18:11:01 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 18 Apr 2016 11:11:01 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <CA+kOe09o3ZV2H7B9amg0Noc9uWsFnLJx8NnKRuNRuGwuWC4=-w@mail.gmail.com>
References: <57070725.1090906@oracle.com>	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>	<570C2BDF.4020202@oracle.com>	<CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>	<570C34A4.7050408@oracle.com>	<CA+kOe099O5aSYx9q64ESyff2vB5v0j+uU_C4rQn+UuQ=1tC5OQ@mail.gmail.com>	<571105F1.1010808@oracle.com>	<CA+kOe0_06Teuzc+G3OCCCERXf4RxhtxFqE6-35xqszhZyR_Dxw@mail.gmail.com>	<CA+kOe0885gV8ACtkUYR7y2bhEje+xVe1qTVDSm=s1qC-sXexuw@mail.gmail.com>
	<CA+kOe09o3ZV2H7B9amg0Noc9uWsFnLJx8NnKRuNRuGwuWC4=-w@mail.gmail.com>
Message-ID: <57152335.2060203@oracle.com>



On 04/16/2016 03:45 PM, Martin Buchholz wrote:
> exec $JDK/bin/javadoc \
>    -d docs \
>    -Xdoclint:all \
>    -Xmodule:java.base \
>    -modulesourcepath "$JDKSRC/jdk/src/java.base/share/classes" \

javadoc folk,

This looks like a bug.  Assuming Martin is using reasonably up to date 
JDK 9 code, you should not be able to specify both -Xmodule and 
-modulesourcepath.

-- Jon

From martinrb at google.com  Mon Apr 18 18:33:24 2016
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 18 Apr 2016 11:33:24 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <57152335.2060203@oracle.com>
References: <57070725.1090906@oracle.com>
	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>
	<570C2BDF.4020202@oracle.com>
	<CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>
	<570C34A4.7050408@oracle.com>
	<CA+kOe099O5aSYx9q64ESyff2vB5v0j+uU_C4rQn+UuQ=1tC5OQ@mail.gmail.com>
	<571105F1.1010808@oracle.com>
	<CA+kOe0_06Teuzc+G3OCCCERXf4RxhtxFqE6-35xqszhZyR_Dxw@mail.gmail.com>
	<CA+kOe0885gV8ACtkUYR7y2bhEje+xVe1qTVDSm=s1qC-sXexuw@mail.gmail.com>
	<CA+kOe09o3ZV2H7B9amg0Noc9uWsFnLJx8NnKRuNRuGwuWC4=-w@mail.gmail.com>
	<57152335.2060203@oracle.com>
Message-ID: <CA+kOe09=PNjfxtXh1+kXSivgS9YpWB7tXr7=cvqKcG9JdVmXTA@mail.gmail.com>

On Mon, Apr 18, 2016 at 11:11 AM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
>
>
> On 04/16/2016 03:45 PM, Martin Buchholz wrote:
>>
>> exec $JDK/bin/javadoc \
>>    -d docs \
>>    -Xdoclint:all \
>>    -Xmodule:java.base \
>>    -modulesourcepath "$JDKSRC/jdk/src/java.base/share/classes" \
>
>
> javadoc folk,
>
> This looks like a bug.  Assuming Martin is using reasonably up to date JDK 9
> code, you should not be able to specify both -Xmodule and -modulesourcepath.

What I'm trying to tell javadoc is that I have some source files that
are logically in the java.base module, and they override (and inherit
from) the full module sources (including module-info.java) that are
somewhere else (in a jdk9 source tree).

From jonathan.gibbons at oracle.com  Mon Apr 18 18:38:56 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 18 Apr 2016 11:38:56 -0700
Subject: Custom Taglets
In-Reply-To: <op.yf4jt415kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>
References: <op.yf4jt415kdkhrr@desktop-2khsk44.dynamic.ziggo.nl>
Message-ID: <571529C0.3090505@oracle.com>



On 04/18/2016 09:52 AM, Robert Scholte wrote:
> Hi,
>
> in preparation of the DevoxxFr talk about Maven and Java9 by Herv? 
> Boutemy and Arnaud H?ritier I noticed some issues with custom taglets 
> when generation Javadoc reports.
>
> For the developers of Maven plugins we have a set of Annotations or 
> DocletTags[1] to generate the plugin descriptor.
> The taglets are based on com.sun.tools.doclets.Taglet, but when trying 
> to run this with Java 9-ea+113 I get the following exception.
>
> Caused by: org.apache.maven.plugin.MojoExecutionException: An error 
> has occurred in JavaDocs report generation:
> Exit code: 1 - javadoc: error - Error - Exception 
> java.lang.ClassCastException thrown while trying to register Taglet 
> org.apache.maven.tools.plugin.javadoc.MojoAggregatorTypeTaglet...
>
> What's the preferred way to write custom Taglets when using Java9 and 
> will this also work with older versions of Java?
>
> thanks,
> Robert
>
> [1] 
> https://maven.apache.org/components/plugin-tools/maven-plugin-tools-javadoc/

Hi Robert,

javadoc in JDK 9 is affected both by JIgsaw, and by the change to use a 
new doclet API, JEP 221, with a relatively complicated compatibility 
strategy going forward.

http://openjdk.java.net/jeps/221

In this case, it looks like you are using the new version of javadoc, 
with the new standard doclet, but using an old-world Taglet. That should 
definitely be supported, and it looks like a bug that it is not.

I have filed
JDK-8154482: new doclet should support old taglets
https://bugs.openjdk.java.net/browse/JDK-8154482

-- Jon


From jonathan.gibbons at oracle.com  Mon Apr 18 19:53:27 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 18 Apr 2016 12:53:27 -0700
Subject: RFR: 8152818: Javadoc must support module options supported by
	javac.
In-Reply-To: <CA+kOe09=PNjfxtXh1+kXSivgS9YpWB7tXr7=cvqKcG9JdVmXTA@mail.gmail.com>
References: <57070725.1090906@oracle.com>	<CA+kOe0_9rRHK8U23pxfBWVk92366ScyvNMvQk=J_q1xBjpqMNw@mail.gmail.com>	<570C2BDF.4020202@oracle.com>	<CA+kOe0-mdytkXuR4qm=2aOyDdvD6ytW6hDUBcueBYSh3mdEe3Q@mail.gmail.com>	<570C34A4.7050408@oracle.com>	<CA+kOe099O5aSYx9q64ESyff2vB5v0j+uU_C4rQn+UuQ=1tC5OQ@mail.gmail.com>	<571105F1.1010808@oracle.com>	<CA+kOe0_06Teuzc+G3OCCCERXf4RxhtxFqE6-35xqszhZyR_Dxw@mail.gmail.com>	<CA+kOe0885gV8ACtkUYR7y2bhEje+xVe1qTVDSm=s1qC-sXexuw@mail.gmail.com>	<CA+kOe09o3ZV2H7B9amg0Noc9uWsFnLJx8NnKRuNRuGwuWC4=-w@mail.gmail.com>	<57152335.2060203@oracle.com>
	<CA+kOe09=PNjfxtXh1+kXSivgS9YpWB7tXr7=cvqKcG9JdVmXTA@mail.gmail.com>
Message-ID: <57153B37.2010905@oracle.com>



On 04/18/2016 11:33 AM, Martin Buchholz wrote:
> On Mon, Apr 18, 2016 at 11:11 AM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>>
>> On 04/16/2016 03:45 PM, Martin Buchholz wrote:
>>> exec $JDK/bin/javadoc \
>>>     -d docs \
>>>     -Xdoclint:all \
>>>     -Xmodule:java.base \
>>>     -modulesourcepath "$JDKSRC/jdk/src/java.base/share/classes" \
>>
>> javadoc folk,
>>
>> This looks like a bug.  Assuming Martin is using reasonably up to date JDK 9
>> code, you should not be able to specify both -Xmodule and -modulesourcepath.
> What I'm trying to tell javadoc is that I have some source files that
> are logically in the java.base module, and they override (and inherit
> from) the full module sources (including module-info.java) that are
> somewhere else (in a jdk9 source tree).


Yes, I understand your intent, and agree it should be possible to do what
you want, in a reasonable way.  We're still trying to figure out the best
way to address your goals.

I was simply noticing/reporting a bug in the tools that allowed you to 
specify an
unreasonable combination of options.

-- Jon


From jonathan.gibbons at oracle.com  Mon Apr 18 22:48:15 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 18 Apr 2016 15:48:15 -0700
Subject: RFR:     8154500 fix handling of jdk.launcher.patch.* in tests
Message-ID: <5715642F.9050009@oracle.com>

The conversion from using sun.boot.class.path to jdk.launcher.patch.* 
was imperfect, and becoming more so with the move towards using multiple 
-Xpatch options, in different system properties.

A more complete/general solution would be shared infrastructure to fork 
tools and inherit selected jdk.launcher properties, but for now, I've 
done "quick and easy".

Bug: https://bugs.openjdk.java.net/browse/JDK-8154500
Review: http://cr.openjdk.java.net/~jjg/8154500/webrev.00/index.html

-- Jon


From kumar.x.srinivasan at oracle.com  Mon Apr 18 23:28:51 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 18 Apr 2016 16:28:51 -0700
Subject: RFR:     8154500 fix handling of jdk.launcher.patch.* in tests
In-Reply-To: <5715642F.9050009@oracle.com>
References: <5715642F.9050009@oracle.com>
Message-ID: <57156DB3.5050701@oracle.com>


Looks fine to me.

Kumar

> The conversion from using sun.boot.class.path to jdk.launcher.patch.* 
> was imperfect, and becoming more so with the move towards using 
> multiple -Xpatch options, in different system properties.
>
> A more complete/general solution would be shared infrastructure to 
> fork tools and inherit selected jdk.launcher properties, but for now, 
> I've done "quick and easy".
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8154500
> Review: http://cr.openjdk.java.net/~jjg/8154500/webrev.00/index.html
>
> -- Jon
>


From kumar.x.srinivasan at oracle.com  Tue Apr 26 19:00:54 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 26 Apr 2016 12:00:54 -0700
Subject: RFR: 8154482: javadoc tool must support legacy doclet and taglet
Message-ID: <571FBAE6.9000709@oracle.com>

Hello,

Please review  fix for:
https://bugs.openjdk.java.net/browse/JDK-8154482

Webrev at:
http://cr.openjdk.java.net/~ksrini/8154482/webrev.00/

Thanks
Kumar


From kumar.x.srinivasan at oracle.com  Thu Apr 28 17:48:18 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 28 Apr 2016 10:48:18 -0700
Subject: RFR: 8154482: javadoc tool must support legacy doclet and taglet
In-Reply-To: <571FBAE6.9000709@oracle.com>
References: <571FBAE6.9000709@oracle.com>
Message-ID: <57224CE2.6090601@oracle.com>


Hello,

Based on the reviews here is the second revision of the fix.
http://cr.openjdk.java.net/~ksrini/8154482/webrev.01/


Highlights of the changes:

1.  Removed the redundant undocumented option -Xnew
2. A doclet on the command lines decides the target,
     irrespective of the taglet variant, this simplifies the logic.
3. Added a new annotation based testcase execution utility,
     in the toolbox package.
4. Added more testcases, refactored the test to use toolbox utilities,
    and other simplifications.

Thanks
Kumar



> Hello,
>
> Please review  fix for:
> https://bugs.openjdk.java.net/browse/JDK-8154482
>
> Webrev at:
> http://cr.openjdk.java.net/~ksrini/8154482/webrev.00/
>
> Thanks
> Kumar
>


From jonathan.gibbons at oracle.com  Thu Apr 28 23:55:35 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 28 Apr 2016 16:55:35 -0700
Subject: RFR: 8154482: javadoc tool must support legacy doclet and taglet
In-Reply-To: <57224CE2.6090601@oracle.com>
References: <571FBAE6.9000709@oracle.com> <57224CE2.6090601@oracle.com>
Message-ID: <5722A2F7.1030405@oracle.com>

Start.java, line 241, 241, use &&, not nested if

Start:490,  generally, the terminology in langtools is to use "path"
to mean a complete search path, as in a series of file system locations,
such as a class path or source path.   With that in mind, the decl
on 490 would be better named "userTagletPath" (singular)
not "userTagletPaths" plural.

Yes, it gets confusing in parts of the code that use the NIO2 type
Path as a replacement for File.  There, the convention is to use
"search path" as the generalization of class path, source path, etc.

Start 598, 605, 616
The use of panic and its use of Messager.exit would be improved
by replacing
     panic(key, args)
     return false; // keep compiler happy
with either
     error(key, args)
     throw new ExitJavadoc();

(Ultimately, Start.exit and Messager.exit should go away.)

javadoc.properties.
118.   Ending a sentence "at the earliest." may be an acceptable
colloquialism, but guardians of the Queen's English would raise
an eyebrow or two.   I would just delete these words.  Yes, we
should recommend that folk migrate, but time is not of the
essence,


new test:
It's OK as it is, but the test-case names are not informative,
and may be tedious to update if you want  to add a new test case
in the middle of the list at some point in the future. Also, the
names are uninformative when they show up in a stack trace.
With this style of test case, I've typically found it useful to
use description names that describe the test case or test
conditions.

TestRunner should have class level javadoc. Thanks for creating
this class.

-- Jon



On 04/28/2016 10:48 AM, Kumar Srinivasan wrote:
>
> Hello,
>
> Based on the reviews here is the second revision of the fix.
> http://cr.openjdk.java.net/~ksrini/8154482/webrev.01/
>
>
> Highlights of the changes:
>
> 1.  Removed the redundant undocumented option -Xnew
> 2. A doclet on the command lines decides the target,
>     irrespective of the taglet variant, this simplifies the logic.
> 3. Added a new annotation based testcase execution utility,
>     in the toolbox package.
> 4. Added more testcases, refactored the test to use toolbox utilities,
>    and other simplifications.
>
> Thanks
> Kumar
>
>
>
>> Hello,
>>
>> Please review  fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8154482
>>
>> Webrev at:
>> http://cr.openjdk.java.net/~ksrini/8154482/webrev.00/
>>
>> Thanks
>> Kumar
>>
>


From jonathan.gibbons at oracle.com  Fri Apr 29 00:51:48 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 28 Apr 2016 17:51:48 -0700
Subject: RFR: 8075703 "jdk.javadoc" module exports "com.sun.tools.javadoc"
	package which contains a lot of internal API.
Message-ID: <5722B024.1070607@oracle.com>

Please review this fix to move internal classes from an exported package.

Although the webrev appears long, the work itself is fundamentally simple:

Using an IDE, all classes in com.sun.tools.javadoc except Main were moved
as one into a subpackage com.sun.tools.javadoc.main.  A few constructors
in Start had to be fixed by hand, by changing their access from 
package-private
to public.

No other changes were made.  All tests continue to pass.

JBS: https://bugs.openjdk.java.net/browse/JDK-8075703
Review: http://cr.openjdk.java.net/~jjg/8075703/webrev.00/

-- Jon



From kumar.x.srinivasan at oracle.com  Fri Apr 29 13:15:44 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 29 Apr 2016 06:15:44 -0700
Subject: RFR: 8075703 "jdk.javadoc" module exports "com.sun.tools.javadoc"
	package which contains a lot of internal API.
In-Reply-To: <5722B024.1070607@oracle.com>
References: <5722B024.1070607@oracle.com>
Message-ID: <57235E80.3090502@oracle.com>


Looks ok to me. The bug should be tagged with an appropriate noreg.
noreg-trivial / noreg-cleanup

Kumar

> Please review this fix to move internal classes from an exported package.
>
> Although the webrev appears long, the work itself is fundamentally 
> simple:
>
> Using an IDE, all classes in com.sun.tools.javadoc except Main were moved
> as one into a subpackage com.sun.tools.javadoc.main.  A few constructors
> in Start had to be fixed by hand, by changing their access from 
> package-private
> to public.
>
> No other changes were made.  All tests continue to pass.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8075703
> Review: http://cr.openjdk.java.net/~jjg/8075703/webrev.00/
>
> -- Jon
>
>


From kumar.x.srinivasan at oracle.com  Fri Apr 29 16:20:38 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 29 Apr 2016 09:20:38 -0700
Subject: RFR: 8155061: javadoc incorrectly sorted items in All Classes list
	and Index files
Message-ID: <572389D6.6050103@oracle.com>

Hello,

Fixes incorrect sorting in the All Classes and Index files.
https://bugs.openjdk.java.net/browse/JDK-8155061

Webrev at:
http://cr.openjdk.java.net/~ksrini/8155061/webrev.00/

Thanks
Kumar

From kumar.x.srinivasan at oracle.com  Fri Apr 29 18:28:13 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 29 Apr 2016 11:28:13 -0700
Subject: RFR: 8154482: javadoc tool must support legacy doclet and taglet
In-Reply-To: <5722A2F7.1030405@oracle.com>
References: <571FBAE6.9000709@oracle.com> <57224CE2.6090601@oracle.com>
	<5722A2F7.1030405@oracle.com>
Message-ID: <5723A7BD.5080804@oracle.com>


Please review, this addresses all your comments below.
http://cr.openjdk.java.net/~ksrini/8154482/webrev.02/

Thanks
Kumar

> Start.java, line 241, 241, use &&, not nested if
>
> Start:490,  generally, the terminology in langtools is to use "path"
> to mean a complete search path, as in a series of file system locations,
> such as a class path or source path.   With that in mind, the decl
> on 490 would be better named "userTagletPath" (singular)
> not "userTagletPaths" plural.
>
> Yes, it gets confusing in parts of the code that use the NIO2 type
> Path as a replacement for File.  There, the convention is to use
> "search path" as the generalization of class path, source path, etc.
>
> Start 598, 605, 616
> The use of panic and its use of Messager.exit would be improved
> by replacing
>     panic(key, args)
>     return false; // keep compiler happy
> with either
>     error(key, args)
>     throw new ExitJavadoc();
>
> (Ultimately, Start.exit and Messager.exit should go away.)
>
> javadoc.properties.
> 118.   Ending a sentence "at the earliest." may be an acceptable
> colloquialism, but guardians of the Queen's English would raise
> an eyebrow or two.   I would just delete these words.  Yes, we
> should recommend that folk migrate, but time is not of the
> essence,
>
>
> new test:
> It's OK as it is, but the test-case names are not informative,
> and may be tedious to update if you want  to add a new test case
> in the middle of the list at some point in the future. Also, the
> names are uninformative when they show up in a stack trace.
> With this style of test case, I've typically found it useful to
> use description names that describe the test case or test
> conditions.
>
> TestRunner should have class level javadoc. Thanks for creating
> this class.
>
> -- Jon
>
>
>
> On 04/28/2016 10:48 AM, Kumar Srinivasan wrote:
>>
>> Hello,
>>
>> Based on the reviews here is the second revision of the fix.
>> http://cr.openjdk.java.net/~ksrini/8154482/webrev.01/
>>
>>
>> Highlights of the changes:
>>
>> 1.  Removed the redundant undocumented option -Xnew
>> 2. A doclet on the command lines decides the target,
>>     irrespective of the taglet variant, this simplifies the logic.
>> 3. Added a new annotation based testcase execution utility,
>>     in the toolbox package.
>> 4. Added more testcases, refactored the test to use toolbox utilities,
>>    and other simplifications.
>>
>> Thanks
>> Kumar
>>
>>
>>
>>> Hello,
>>>
>>> Please review  fix for:
>>> https://bugs.openjdk.java.net/browse/JDK-8154482
>>>
>>> Webrev at:
>>> http://cr.openjdk.java.net/~ksrini/8154482/webrev.00/
>>>
>>> Thanks
>>> Kumar
>>>
>>
>


From jonathan.gibbons at oracle.com  Fri Apr 29 21:55:14 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 29 Apr 2016 14:55:14 -0700
Subject: RFR: 8155061: javadoc incorrectly sorted items in All Classes
	list and Index files
In-Reply-To: <572389D6.6050103@oracle.com>
References: <572389D6.6050103@oracle.com>
Message-ID: <5723D842.3010900@oracle.com>

OK

On 04/29/2016 09:20 AM, Kumar Srinivasan wrote:
> Hello,
>
> Fixes incorrect sorting in the All Classes and Index files.
> https://bugs.openjdk.java.net/browse/JDK-8155061
>
> Webrev at:
> http://cr.openjdk.java.net/~ksrini/8155061/webrev.00/
>
> Thanks
> Kumar


From jonathan.gibbons at oracle.com  Fri Apr 29 21:58:33 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 29 Apr 2016 14:58:33 -0700
Subject: RFR: 8154482: javadoc tool must support legacy doclet and taglet
In-Reply-To: <5723A7BD.5080804@oracle.com>
References: <571FBAE6.9000709@oracle.com> <57224CE2.6090601@oracle.com>
	<5722A2F7.1030405@oracle.com> <5723A7BD.5080804@oracle.com>
Message-ID: <5723D909.7090806@oracle.com>

OK, but one has to wonder why ExitJavadoc is defined in Messager, and not
at the top level.

-- Jon

On 04/29/2016 11:28 AM, Kumar Srinivasan wrote:
>
> Please review, this addresses all your comments below.
> http://cr.openjdk.java.net/~ksrini/8154482/webrev.02/
>
> Thanks
> Kumar
>
>> Start.java, line 241, 241, use &&, not nested if
>>
>> Start:490,  generally, the terminology in langtools is to use "path"
>> to mean a complete search path, as in a series of file system locations,
>> such as a class path or source path.   With that in mind, the decl
>> on 490 would be better named "userTagletPath" (singular)
>> not "userTagletPaths" plural.
>>
>> Yes, it gets confusing in parts of the code that use the NIO2 type
>> Path as a replacement for File.  There, the convention is to use
>> "search path" as the generalization of class path, source path, etc.
>>
>> Start 598, 605, 616
>> The use of panic and its use of Messager.exit would be improved
>> by replacing
>>     panic(key, args)
>>     return false; // keep compiler happy
>> with either
>>     error(key, args)
>>     throw new ExitJavadoc();
>>
>> (Ultimately, Start.exit and Messager.exit should go away.)
>>
>> javadoc.properties.
>> 118.   Ending a sentence "at the earliest." may be an acceptable
>> colloquialism, but guardians of the Queen's English would raise
>> an eyebrow or two.   I would just delete these words.  Yes, we
>> should recommend that folk migrate, but time is not of the
>> essence,
>>
>>
>> new test:
>> It's OK as it is, but the test-case names are not informative,
>> and may be tedious to update if you want  to add a new test case
>> in the middle of the list at some point in the future. Also, the
>> names are uninformative when they show up in a stack trace.
>> With this style of test case, I've typically found it useful to
>> use description names that describe the test case or test
>> conditions.
>>
>> TestRunner should have class level javadoc. Thanks for creating
>> this class.
>>
>> -- Jon
>>
>>
>>
>> On 04/28/2016 10:48 AM, Kumar Srinivasan wrote:
>>>
>>> Hello,
>>>
>>> Based on the reviews here is the second revision of the fix.
>>> http://cr.openjdk.java.net/~ksrini/8154482/webrev.01/
>>>
>>>
>>> Highlights of the changes:
>>>
>>> 1.  Removed the redundant undocumented option -Xnew
>>> 2. A doclet on the command lines decides the target,
>>>     irrespective of the taglet variant, this simplifies the logic.
>>> 3. Added a new annotation based testcase execution utility,
>>>     in the toolbox package.
>>> 4. Added more testcases, refactored the test to use toolbox utilities,
>>>    and other simplifications.
>>>
>>> Thanks
>>> Kumar
>>>
>>>
>>>
>>>> Hello,
>>>>
>>>> Please review  fix for:
>>>> https://bugs.openjdk.java.net/browse/JDK-8154482
>>>>
>>>> Webrev at:
>>>> http://cr.openjdk.java.net/~ksrini/8154482/webrev.00/
>>>>
>>>> Thanks
>>>> Kumar
>>>>
>>>
>>
>


From kumar.x.srinivasan at oracle.com  Sat Apr 30 14:50:30 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Sat, 30 Apr 2016 07:50:30 -0700
Subject: 8154578: Drop residual use of addReads from javadoc
Message-ID: <5724C636.1000001@oracle.com>

Hello,

Please review this easy fix.

http://cr.openjdk.java.net/~ksrini/8154578
https://bugs.openjdk.java.net/browse/JDK-8154578

Thanks
Kumar


From Alan.Bateman at oracle.com  Sat Apr 30 15:32:33 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 30 Apr 2016 16:32:33 +0100
Subject: 8154578: Drop residual use of addReads from javadoc
In-Reply-To: <5724C636.1000001@oracle.com>
References: <5724C636.1000001@oracle.com>
Message-ID: <5724D011.5060903@oracle.com>



On 30/04/2016 15:50, Kumar Srinivasan wrote:
> Hello,
>
> Please review this easy fix.
>
> http://cr.openjdk.java.net/~ksrini/8154578
> https://bugs.openjdk.java.net/browse/JDK-8154578
This looks fine.