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



Reply via email to