maven-javadoc-plugin failure due to StringIndexOutOfBoundsException

Question

I always got StringIndexOutOfBoundsException issue when running mvn javadoc:javadoc. Anyone know about this error? Below is the full stack trace:

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Java Tool 0.2
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> maven-javadoc-plugin:2.9:javadoc (default-cli) @ osgl-tool >>>
[INFO]
[INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-maven) @ osgl-tool ---
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9:javadoc (default-cli) @ osgl-tool <<<
[INFO]
[INFO] --- maven-javadoc-plugin:2.9:javadoc (default-cli) @ osgl-tool ---
[INFO]
Loading source files for package org.osgl.exception...
Loading source files for package org.osgl.util.algo...
Loading source files for package org.osgl.util...
Loading source files for package org.osgl.web.util...
Loading source files for package org.osgl...
Constructing Javadoc information...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.890s
[INFO] Finished at: Tue Feb 18 21:05:48 EST 2014
[INFO] Final Memory: 10M/242M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (default-cli) on project osgl-tool: An error has occurred in JavaDocs report generation:
[ERROR] Exit code: 1 - java.lang.StringIndexOutOfBoundsException: String index out of range: -22
[ERROR] at java.lang.String.substring(String.java:1937)
[ERROR] at java.lang.String.substring(String.java:1904)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.simpleBinaryName(ClassReader.java:958)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.readEnclosingMethodAttr(ClassReader.java:930)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.readMemberAttr(ClassReader.java:909)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.readClassAttr(ClassReader.java:1053)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.readClassAttrs(ClassReader.java:1067)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:1560)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:1658)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:1845)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1777)
[ERROR] at com.sun.tools.javac.code.Symbol.complete(Symbol.java:384)
[ERROR] at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:766)
[ERROR] at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:698)
[ERROR] at com.sun.tools.javadoc.ClassDocImpl.getFlags(ClassDocImpl.java:103)
[ERROR] at com.sun.tools.javadoc.ClassDocImpl.isAnnotationType(ClassDocImpl.java:114)
[ERROR] at com.sun.tools.javadoc.DocEnv.isAnnotationType(DocEnv.java:572)
[ERROR] at com.sun.tools.javadoc.DocEnv.getClassDoc(DocEnv.java:544)
[ERROR] at com.sun.tools.javadoc.PackageDocImpl.getClasses(PackageDocImpl.java:154)
[ERROR] at com.sun.tools.javadoc.PackageDocImpl.addAllClassesTo(PackageDocImpl.java:170)
[ERROR] at com.sun.tools.javadoc.RootDocImpl.classes(RootDocImpl.java:178)
[ERROR] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:96)
[ERROR] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64)
[ERROR] at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42)
[ERROR] at com.sun.tools.doclets.standard.Standard.start(Standard.java:23)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:597)
[ERROR] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269)
[ERROR] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143)
[ERROR] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340)
[ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:128)
[ERROR] at com.sun.tools.javadoc.Main.execute(Main.java:41)
[ERROR] at com.sun.tools.javadoc.Main.main(Main.java:31)
[ERROR]
[ERROR] Command line was: R:\jdk\jre\..\bin\javadoc.exe @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in 'c:\p\java-tool\target\site\apidocs' dir.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

Notes

Yes, I am using eclipse compiler
The answers to question Using Eclipse compiler instead of javac results in javadoc crash don't help out
Now I switched to java compiler, but it still doesn't work
Here is a single java file (which is okay to compile) that will fail when running javadoc on it: https://github.com/greenlaw110/java-tool/blob/master/src/main/java/org/osgl/_.java
pom.xml issue with cycling dependencies is NOT relevant to this issue. Removing the cyclic dependencies following Aleksandr's answer does make the project able to build and even able to build with 'mvn package -Pdist', but it doesn't solve the javadoc issue. The reason you can build and generate the javadoc is I've removed the issue packages with <excludePackageNames>org.osgl:org.osgl.util</excludePackageNames>. Try to take that line out of the pom.xml and run mvn clean package -Pdist again to reproduce the javadoc issue
I choose _ as the class name following the underscore.js project. It is used to aggregate some common utilities into a meta-alike namespace. For people who doesn't like, just use Osgl to replace _ as they alias each other
It's really weird that after I cloned the project in my linux box on digital ocean and it does built success. Something must be wrong with my windows dev machine!
Issue resolved! Removing the cyclic dependency does solve the issue. My guess is that cyclic dependency brings back old osgl-tool pom.xml version which use eclipse to compile the code and conflict with javadoc

Do the answers to this question help at all? http://stackoverflow.com/questions/8190649/using-eclipse-compiler-instead-of-javac-results-in-javadoc-crash — DB5, Feb 18 '14 at 10:27
I read that question already. But it doesn't help. That's why I ask another one here — Gelin Luo, Feb 18 '14 at 10:30
You should try to create a minimal example (delete every class that does not cause problems) and see what you are left with. — Tunaki, Feb 26 '15 at 11:29
Updated the question with a link to the source file that caused the issue — Gelin Luo, Feb 27 '15 at 10:16
What a bizarre class name! Any reason you named it like that? Or is it some strange way to organically obfuscate one's code? — Jagger, Feb 27 '15 at 12:29
`_` is a [valid class name](http://stackoverflow.com/questions/65475/valid-characters-in-a-java-class-name) and actually the original org.osgl:osgl-tool implementation has [this same class](http://grepcode.com/file/repo1.maven.org/maven2/org.osgl/osgl-tool/0.2/org/osgl/_.java?av=f). — ericbn, Feb 27 '15 at 12:44
Valid doesn't mean it is a good practice - *The "Java letters" include uppercase and lowercase ASCII Latin letters A-Z (\u0041-\u005a), and a-z (\u0061-\u007a), and, for historical reasons, the ASCII underscore (_, or \u005f) and dollar sign ($, or \u0024).* — Aleksandr M, Feb 27 '15 at 12:53
@ericbn: *The original* impl that you are referring to is actually same project. And you still haven't answered my comment to your answer. — Aleksandr M, Feb 27 '15 at 12:57

Aleksandr M · Accepted Answer · 2015-02-27T14:07:57.840

2

Your problem is in your pom.xml file. You are declaring the org.osgl:osgl-storage dependency which has dependency on org.osgl:osgl-tool - the same project that you are trying to build, but with different version. Exclude this transitive dependency and it is should work.

<dependency>
    <groupId>org.osgl</groupId>
    <artifactId>osgl-storage</artifactId>
    <version>0.3-SNAPSHOT</version>
    <scope>provided</scope>
    <exclusions>
        <exclusion>
            <groupId>org.osgl</groupId>
            <artifactId>osgl-tool</artifactId>
        </exclusion>
    </exclusions>
</dependency>

edited Feb 27 '15 at 14:07

answered Feb 27 '15 at 11:36

Aleksandr M

24,264
12
69
143

Thanks for pointing out the latest pom.xml bug. But this is not relevant to the javadoc issue. See my updates to the question – Gelin Luo Feb 27 '15 at 19:28
@green: Are you sure? Have you executed `mvn clean` before running javadoc? I've removed `excludePackageNames` when I was testing that out. – Aleksandr M Feb 27 '15 at 19:40
yes by removing the `` I was not able to run javadoc through. I am on windows 7 and use java 1.7.0_67 – Gelin Luo Feb 27 '15 at 19:45
I've just pushed my changes to pom.xml file to master branch. If you pull the project and run `mvn clean package -Pdist` if you should be able to reproduce the issue – Gelin Luo Feb 27 '15 at 19:46
@green: Just pulled your changes, **added exclusion** and `mvn clean package -Pdist` resulted in build success. – Aleksandr M Feb 27 '15 at 19:49
It's really weird, I cloned the project in my linux box on digital ocean and it does built success. Something must be run with my windows dev machine! – Gelin Luo Feb 27 '15 at 19:54
@green: You can try to clean your .m2 directory, maybe it some cache issue. BTW I was testing this on win7, java 1.7.0.65. – Aleksandr M Feb 27 '15 at 19:57
nope, cleaned my .m2 directory and I still got that issue. Also if I run generate javadoc from intellij idea I will get the same issue – Gelin Luo Feb 27 '15 at 20:11
Have you tried from the console? Also are you sure that you've added the exclusion? Because it wasn't there in your last commit. – Aleksandr M Feb 27 '15 at 20:14
I did tried `mvn clean package -Pdist` from the console. I've taken out the dependencies exclusion. My pom.xml is now sync to github master head – Gelin Luo Feb 27 '15 at 20:21
You have to add the exclusion to `osgl-storage` dependency, like in my answer. :) – Aleksandr M Feb 27 '15 at 20:25
Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/71907/discussion-between-green-and-aleksandr-m). – Gelin Luo Feb 27 '15 at 20:29

ericbn · Answer 2 · 2015-02-27T14:47:36.043

If you do mvn dependency:tree you'll see that org.osgl:osgl-storage:jar:0.3-SNAPSHOT is bringing org.osgl:osgl-tool:jar:0.3-SNAPSHOT as a dependency too, which will conflict with you own version of this same artifact.

[INFO] org.osgl:osgl-tool:jar:0.4.1-SNAPSHOT
[INFO] +- junit:junit:jar:4.10:test
[INFO] |  \- org.hamcrest:hamcrest-core:jar:1.1:test
[INFO] +- commons-codec:commons-codec:jar:1.8:compile
[INFO] +- com.carrotsearch:junit-benchmarks:jar:0.7.2:test
[INFO] \- org.osgl:osgl-storage:jar:0.3-SNAPSHOT:provided
[INFO]    +- org.osgl:osgl-tool:jar:0.3-SNAPSHOT:provided
[INFO]    \- org.osgl:osgl-logging:jar:0.2:provided

All you need to do is tell Maven to exclude this transitive dependency:

<dependency>
  <groupId>org.osgl</groupId>
  <artifactId>osgl-storage</artifactId>
  <version>0.3-SNAPSHOT</version>
  <scope>provided</scope>
  <exclusions>
    <exclusion>
      <groupId>org.osgl</groupId>
      <artifactId>osgl-tool</artifactId>
    </exclusion>
  </exclusions>
</dependency>

What happened is you had two versions of the same artifact together (your 0.4.1-SNAPSHOT and the other 0.3-SNAPSHOT version). The solution above excludes the 0.3-SNAPSHOT version brought transitively by org.osgl:osgl-storage:jar:0.3-SNAPSHOT.

You also created a cyclic dependency by making your org.osgl:osgl-tool depend on org.osgl:osgl-storage, since org.osgl:osgl-storage originally depends on org.osgl:osgl-tool.

org.osgl:osgl-storage <──┐ ... you added this dependency
     │                   │
     └──> org.osgl:osgl-tool

Your org.osgl.util.IO class is the one that depends on org.osgl.storage.ISObject and org.osgl.storage.impl.SObject. You should avoid cyclic dependencies if you don't want further issues.

EDIT: Regarding the _ class, it has a valid name. But if such name is being used to avoid repeating a long class name, like in your example:

void foo(_.Func2<Integer, String> f) {
    F2<Integer, String> newF = _.f2(f);
    ...
}

then you should consider renaming the class and using static imports:

import static org.osgl.Osgl.*; // Osgl instead of _

void foo(Func2<Integer, String> f) { // Func2 statically imported
    F2<Integer, String> newF = f2(f); // f2 statically imported
    ...
}

Don't need to touch the `_` class. Just removing the cyclic dependency works. — ericbn, Feb 27 '15 at 12:29
Just renaming the class and keeping the cyclic dependency gives the same error. As I said, this `_` class has nothing to do with this issue. Try it yourself! — ericbn, Feb 27 '15 at 13:08
Follow my answer. The fact that just removing the cyclic dependency works is enough evidence to say anything else has nothing to do with the problem. — ericbn, Feb 27 '15 at 13:32
Your solution works because you will have the exact same classes in 0.3-SNAPSHOT and 0.4.1-SNAPSHOT versions, thus removing any conflict that could occur. Try your solution **without** renaming the class. Works too! Use the Java 7 compiler. — ericbn, Feb 27 '15 at 13:40
You are right about that renaming won't fix this problem, still it is a bad practice to have such name. — Aleksandr M, Feb 27 '15 at 14:12
Thanks guys for the discussion. I've updated the question in replying your comments — Gelin Luo, Feb 27 '15 at 19:41

maven-javadoc-plugin failure due to StringIndexOutOfBoundsException

2 Answers2