Javadoc tool not handling nested anonymous classes

[Jonathan Gibbons]

Thanks.

-- Jon

On 01/08/2018 03:02 PM, Jason Tedor wrote:
> Sure:
>
> $ git clone https://github.com/elastic/elasticsearch.git 
> <mailto: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 <mailto: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
>>     <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/391e84b4/attachment-0001.html>