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 <[email protected]> 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: > > $ 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 :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). > > This requires at least Gradle 4.3. The block of code that it is tripping > on is here: > https://github.com/elastic/elasticsearch/blob/c831442352c00f6cf840ffc3cbae64694935ce8b/core/src/main/java/org/elasticsearch/rest/action/cat/RestThreadPoolAction.java#L78-L98 > > > 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 >
