Javadoc tool not handling nested anonymous classes

[Jonathan Gibbons]

That would help. Thanks.

-- Jon

On 01/08/2018 02:45 PM, Jason Tedor wrote:
> Jonathan: If it helps, I can show you how to use Gradle to produce the 
> arguments that are passed to the javadoc command line, and then you'll 
> have a pure javadoc command line that you can use to reproduce the issue?
>
> On Mon, Jan 8, 2018 at 4:31 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     I spent hour on Friday trying to create a small test case, but
>     without success so far. It seems notable that the example you list
>     in your source code is a lambda whose body contains 3 levels of
>     nested anon classes.
>
>     In general, I strongly dislike having to debug javac code
>     involving large external build systems like Maven and Gradle, but
>     I guess it may become necessary here.
>
>     At any rate, I note you have a workaround, since you say you have
>     ways to run javadoc that does not trigger the error.
>
>     -- Jon
>
>
>     On 1/8/18 1:13 PM, Jason Tedor wrote:
>>     Thanks Jonathan. To clarify, is that something that you will do
>>     or are you expecting me to take action here?
>>
>>     On Fri, Jan 5, 2018 at 4:35 PM Jonathan Gibbons
>>     <jonathan.gibbons at oracle.com
>>     <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>>         Jason,
>>
>>         Thanks for the experiments and report.  It sounds like we can
>>         make a very reduced test case from that.
>>
>>         -- Jon
>>
>>
>>         On 01/05/2018 01:30 PM, Jason Tedor wrote:
>>>         Thanks again for your replies Jonathan, this is helpful.
>>>
>>>         > I see that one possibility may be the presence of source
>>>         code on the source or class path, and equivalent
>>>         previously-compiled classes on the class path.
>>>
>>>         This is indeed the case, the compiled classes are on the
>>>         -classpath passed to the invocation of javadoc; we are not
>>>         specifying --source-path in our invocation.
>>>
>>>         > If that is what is happening for you, that may indicate a
>>>         bug in javac (which is the front end for javadoc, and which
>>>         should handle this situation).
>>>
>>>         Indeed.
>>>
>>>         > The workaround for you would be to try and ensure that you
>>>         don't have sources and equivalent compiled classes on your
>>>         source/classpath for javadoc.
>>>
>>>         If I remove compiling these classes before running javadoc
>>>         then this error does not occur.
>>>
>>>         > I am following up with javac folk to see if there is an
>>>         issue there.
>>>
>>>         Thanks, please let me know what you find out.
>>>
>>>         Again, thank you for your help.
>>>
>>>         On Thu, Jan 4, 2018 at 7:40 PM Jonathan Gibbons
>>>         <jonathan.gibbons at oracle.com
>>>         <mailto:jonathan.gibbons at oracle.com>> wrote:
>>>
>>>
>>>
>>>             On 01/04/2018 04:37 PM, Jonathan Gibbons wrote:
>>>             >
>>>             > One other change may be relevant: JDK-8177588, in
>>>             which we made
>>>             > javadoc be more strict when it encounters compilation
>>>             errors. This was
>>>             > fix in JDK 10 b10.
>>>             >
>>>
>>>             We can probably take this off the table, as the fix
>>>             originally appeared
>>>             in JDK 9.
>>>
>>>             -- Jon
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20180108/f558b06b/attachment.html>