Javadoc tool not handling nested anonymous classes

[Jason Tedor]

Sure:

$ git clone https://github.com/elastic/elasticsearch.git
<git at github.com:elastic/elasticsearch.git>
$ cd elasticsearch
$ git checkout c831442352c00f6cf840ffc3cbae64694935ce8b
$ JAVA_HOME=/path/to/jdk-10 gradle clean :core:javadoc

this will fail and the build will say

> Javadoc generation failed. Generated Javadoc options file (useful for
troubleshooting):
'/home/jason/src/elastic/elasticsearch/core/build/tmp/javadoc/javadoc.options'

where of course the above path will be slightly different for you (let's
call it /path/to/javadoc.options). Then you can say:

$ /path/to/jdk-10/bin/javadoc @/path/to/javadoc.options and the error will
reproduce

Now Gradle is removed from the equation and the
file /path/to/javadoc.options contains all the command line arguments that
are passed to javadoc.


On Mon, Jan 8, 2018 at 5:47 PM Jonathan Gibbons <jonathan.gibbons at oracle.com>
wrote:

> 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> 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> 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> 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/b07b872e/attachment.html>