Javadoc tool not handling nested anonymous classes

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Javadoc tool not handling nested anonymous classes

Jason Tedor
We are seeing this error on JDK 10-ea+35 and JDK 10-ea+36 on all environments (have not tested earlier builds):

javadoc: error - An internal exception has occurred. 
        (com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /home/jason/src/elastic/elasticsearch/core/build/classes/java/main/org/elasticsearch/rest/action/cat/RestThreadPoolAction$1$1.class
  bad enclosing class for org.elasticsearch.rest.action.cat.RestThreadPoolAction$1$1: org.elasticsearch.rest.action.cat.RestThreadPoolAction$1
  Please remove or make sure it appears in the correct subdirectory of the classpath.)
Please file a bug against the javadoc tool via the Java bug reporting page
(http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com)
for duplicates. Include error messages and the following diagnostic in your report. Thank you.
com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /home/jason/src/elastic/elasticsearch/core/build/classes/java/main/org/elasticsearch/rest/action/cat/RestThreadPoolAction$1$1.class
  bad enclosing class for org.elasticsearch.rest.action.cat.RestThreadPoolAction$1$1: org.elasticsearch.rest.action.cat.RestThreadPoolAction$1
  Please remove or make sure it appears in the correct subdirectory of the classpath.

This looks similar to https://bugs.openjdk.java.net/browse/JDK-8151191 which is marked as resolved in JDK 9. This issue does not reproduce in JDK 9.

To reproduce this:

$ git clone https://[hidden email]
$ cd elasticsearch
$ git checkout c831442352c00f6cf840ffc3cbae64694935ce8b
$ JAVA_HOME=/path/to/jdk-10 gradle :core:javadoc

The specific revision is required because I am going to push a change to disable Javadoc builds on JDK 10 for now so that we can get our JDK 10 builds green. The path should be a path to the root of a JDK 10 installation (e.g., the parent directory to bin).


Reply | Threaded
Open this post in threaded view
|

Re: Javadoc tool not handling nested anonymous classes

Jonathan Gibbons


On 12/21/2017 02:07 PM, Jason Tedor wrote:
We are seeing this error on JDK 10-ea+35 and JDK 10-ea+36 on all environments (have not tested earlier builds):

javadoc: error - An internal exception has occurred. 
        (com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /home/jason/src/elastic/elasticsearch/core/build/classes/java/main/org/elasticsearch/rest/action/cat/RestThreadPoolAction$1$1.class
  bad enclosing class for org.elasticsearch.rest.action.cat.RestThreadPoolAction$1$1: org.elasticsearch.rest.action.cat.RestThreadPoolAction$1
  Please remove or make sure it appears in the correct subdirectory of the classpath.)
Please file a bug against the javadoc tool via the Java bug reporting page
(http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com)
for duplicates. Include error messages and the following diagnostic in your report. Thank you.
com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /home/jason/src/elastic/elasticsearch/core/build/classes/java/main/org/elasticsearch/rest/action/cat/RestThreadPoolAction$1$1.class
  bad enclosing class for org.elasticsearch.rest.action.cat.RestThreadPoolAction$1$1: org.elasticsearch.rest.action.cat.RestThreadPoolAction$1
  Please remove or make sure it appears in the correct subdirectory of the classpath.

This looks similar to https://bugs.openjdk.java.net/browse/JDK-8151191 which is marked as resolved in JDK 9. This issue does not reproduce in JDK 9.

To reproduce this:

$ cd elasticsearch
$ git checkout c831442352c00f6cf840ffc3cbae64694935ce8b
$ JAVA_HOME=/path/to/jdk-10 gradle :core:javadoc

The specific revision is required because I am going to push a change to disable Javadoc builds on JDK 10 for now so that we can get our JDK 10 builds green. The path should be a path to the root of a JDK 10 installation (e.g., the parent directory to bin).



Jason,

This looks more like a problem with your environment than a problem with javadoc.  The key message that javadoc is reporting is this:

javadoc: error - An internal exception has occurred. 
        (com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /home/jason/src/elastic/elasticsearch/core/build/classes/java/main/org/elasticsearch/rest/action/cat/RestThreadPoolAction$1$1.class
  bad enclosing class for org.elasticsearch.rest.action.cat.RestThreadPoolAction$1$1: org.elasticsearch.rest.action.cat.RestThreadPoolAction$1
  Please remove or make sure it appears in the correct subdirectory of the classpath.)


I suggest you investigate why you might be having problems with the compiled class files. This sort of error is typically due to mutually inconsistent classes on your classpath, perhaps due to multiple compilations.

At any rate, beyond the javadoc tool giving poor advice about filing a bug, this is not a javadoc issue: the root of the problem lies with what happened before you ran javadoc.

-- Jon
Reply | Threaded
Open this post in threaded view
|

Re: Javadoc tool not handling nested anonymous classes

Jason Tedor
Thanks for the reply Jonathan, I appreciate it. I did read the entire error message and I'm sorry to have to disagree with your assessment (I am not saying you're wrong, only that with the information I have I disagree with you). These are on clean builds in our CI environment, and this reproduces on a clean checkout on every build. This is not an issue with JDK 8 and JDK 9, only with the latest JDK 10 builds. I would like to point out that our entire test suite otherwise passes on JDK 10 which indicates to me that the JDK 10 runtime is otherwise happy with the compiled classes. I agree this very well could be indicative of not a bug in javadoc, but instead in javac but right now all signs are pointing me to javadoc, and most certainly not a problem with my environment. Would you please take a closer look, it feels like a bug in JDK 10?

On Thu, Jan 4, 2018 at 6:47 PM Jonathan Gibbons <[hidden email]> wrote:


On 12/21/2017 02:07 PM, Jason Tedor wrote:
We are seeing this error on JDK 10-ea+35 and JDK 10-ea+36 on all environments (have not tested earlier builds):

javadoc: error - An internal exception has occurred. 
        (com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /home/jason/src/elastic/elasticsearch/core/build/classes/java/main/org/elasticsearch/rest/action/cat/RestThreadPoolAction$1$1.class
  bad enclosing class for org.elasticsearch.rest.action.cat.RestThreadPoolAction$1$1: org.elasticsearch.rest.action.cat.RestThreadPoolAction$1
  Please remove or make sure it appears in the correct subdirectory of the classpath.)
Please file a bug against the javadoc tool via the Java bug reporting page
(http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com)
for duplicates. Include error messages and the following diagnostic in your report. Thank you.
com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /home/jason/src/elastic/elasticsearch/core/build/classes/java/main/org/elasticsearch/rest/action/cat/RestThreadPoolAction$1$1.class
  bad enclosing class for org.elasticsearch.rest.action.cat.RestThreadPoolAction$1$1: org.elasticsearch.rest.action.cat.RestThreadPoolAction$1
  Please remove or make sure it appears in the correct subdirectory of the classpath.

This looks similar to https://bugs.openjdk.java.net/browse/JDK-8151191 which is marked as resolved in JDK 9. This issue does not reproduce in JDK 9.

To reproduce this:

$ cd elasticsearch
$ git checkout c831442352c00f6cf840ffc3cbae64694935ce8b
$ JAVA_HOME=/path/to/jdk-10 gradle :core:javadoc

The specific revision is required because I am going to push a change to disable Javadoc builds on JDK 10 for now so that we can get our JDK 10 builds green. The path should be a path to the root of a JDK 10 installation (e.g., the parent directory to bin).



Jason,

This looks more like a problem with your environment than a problem with javadoc.  The key message that javadoc is reporting is this:


javadoc: error - An internal exception has occurred. 
        (com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /home/jason/src/elastic/elasticsearch/core/build/classes/java/main/org/elasticsearch/rest/action/cat/RestThreadPoolAction$1$1.class
  bad enclosing class for org.elasticsearch.rest.action.cat.RestThreadPoolAction$1$1: org.elasticsearch.rest.action.cat.RestThreadPoolAction$1
  Please remove or make sure it appears in the correct subdirectory of the classpath.)


I suggest you investigate why you might be having problems with the compiled class files. This sort of error is typically due to mutually inconsistent classes on your classpath, perhaps due to multiple compilations.

At any rate, beyond the javadoc tool giving poor advice about filing a bug, this is not a javadoc issue: the root of the problem lies with what happened before you ran javadoc.

-- Jon
Reply | Threaded
Open this post in threaded view
|

Re: Javadoc tool not handling nested anonymous classes

Jonathan Gibbons

Just because it worked before, and repeatedly works on a clean build, does not make the environment setup inherently correct ;-)

Reading a lot of the background material, including other similar bugs, 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.  That would typically not happen for javac, when you are still compiling the source code) or be a problem at runtime (when the source would not be present) but may plausibly occur when running javadoc.   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). 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.  I am following up with javac folk to see if there is an issue there.

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.

-- Jon


On 1/4/18 4:19 PM, Jason Tedor wrote:
Thanks for the reply Jonathan, I appreciate it. I did read the entire error message and I'm sorry to have to disagree with your assessment (I am not saying you're wrong, only that with the information I have I disagree with you). These are on clean builds in our CI environment, and this reproduces on a clean checkout on every build. This is not an issue with JDK 8 and JDK 9, only with the latest JDK 10 builds. I would like to point out that our entire test suite otherwise passes on JDK 10 which indicates to me that the JDK 10 runtime is otherwise happy with the compiled classes. I agree this very well could be indicative of not a bug in javadoc, but instead in javac but right now all signs are pointing me to javadoc, and most certainly not a problem with my environment. Would you please take a closer look, it feels like a bug in JDK 10?

On Thu, Jan 4, 2018 at 6:47 PM Jonathan Gibbons <[hidden email]> wrote:


On 12/21/2017 02:07 PM, Jason Tedor wrote:
We are seeing this error on JDK 10-ea+35 and JDK 10-ea+36 on all environments (have not tested earlier builds):

javadoc: error - An internal exception has occurred. 
        (com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /home/jason/src/elastic/elasticsearch/core/build/classes/java/main/org/elasticsearch/rest/action/cat/RestThreadPoolAction$1$1.class
  bad enclosing class for org.elasticsearch.rest.action.cat.RestThreadPoolAction$1$1: org.elasticsearch.rest.action.cat.RestThreadPoolAction$1
  Please remove or make sure it appears in the correct subdirectory of the classpath.)
Please file a bug against the javadoc tool via the Java bug reporting page
(http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com)
for duplicates. Include error messages and the following diagnostic in your report. Thank you.
com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /home/jason/src/elastic/elasticsearch/core/build/classes/java/main/org/elasticsearch/rest/action/cat/RestThreadPoolAction$1$1.class
  bad enclosing class for org.elasticsearch.rest.action.cat.RestThreadPoolAction$1$1: org.elasticsearch.rest.action.cat.RestThreadPoolAction$1
  Please remove or make sure it appears in the correct subdirectory of the classpath.

This looks similar to https://bugs.openjdk.java.net/browse/JDK-8151191 which is marked as resolved in JDK 9. This issue does not reproduce in JDK 9.

To reproduce this:

$ cd elasticsearch
$ git checkout c831442352c00f6cf840ffc3cbae64694935ce8b
$ JAVA_HOME=/path/to/jdk-10 gradle :core:javadoc

The specific revision is required because I am going to push a change to disable Javadoc builds on JDK 10 for now so that we can get our JDK 10 builds green. The path should be a path to the root of a JDK 10 installation (e.g., the parent directory to bin).



Jason,

This looks more like a problem with your environment than a problem with javadoc.  The key message that javadoc is reporting is this:


javadoc: error - An internal exception has occurred. 
        (com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /home/jason/src/elastic/elasticsearch/core/build/classes/java/main/org/elasticsearch/rest/action/cat/RestThreadPoolAction$1$1.class
  bad enclosing class for org.elasticsearch.rest.action.cat.RestThreadPoolAction$1$1: org.elasticsearch.rest.action.cat.RestThreadPoolAction$1
  Please remove or make sure it appears in the correct subdirectory of the classpath.)


I suggest you investigate why you might be having problems with the compiled class files. This sort of error is typically due to mutually inconsistent classes on your classpath, perhaps due to multiple compilations.

At any rate, beyond the javadoc tool giving poor advice about filing a bug, this is not a javadoc issue: the root of the problem lies with what happened before you ran javadoc.

-- Jon

Reply | Threaded
Open this post in threaded view
|

Re: Javadoc tool not handling nested anonymous classes

Jonathan Gibbons


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 | Threaded
Open this post in threaded view
|

Re: Javadoc tool not handling nested anonymous classes

Jason Tedor
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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Javadoc tool not handling nested anonymous classes

Jonathan Gibbons
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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Javadoc tool not handling nested anonymous classes

Jason Tedor
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 <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Javadoc tool not handling nested anonymous classes

Jonathan Gibbons

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 <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Javadoc tool not handling nested anonymous classes

Jason Tedor
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Javadoc tool not handling nested anonymous classes

Jonathan Gibbons
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Javadoc tool not handling nested anonymous classes

Jason Tedor
Sure:

$ git clone https://[hidden email]
$ 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Javadoc tool not handling nested anonymous classes

Jonathan Gibbons
Thanks.

-- Jon

On 01/08/2018 03:02 PM, Jason Tedor wrote:
Sure:

$ 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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