Sure: $ git clone https://github.com/elastic/elasticsearch.git <[email protected]: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 <[email protected]> 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 < > [email protected]> 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 < >> [email protected]> 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 < >>> [email protected]> 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 >>>> >>> >>> >> >
