Thanks.
-- Jon
On 01/08/2018 03:02 PM, Jason Tedor wrote:
Sure:
$ git clone https://github.com/elastic/elasticsearch.git
<mailto:[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] <mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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
