java.lang.IllegalStateException: endPosTable alrea

问题:

Trying to build an alexa (amazon:echo) skills set. At the same time, trying to use this experience as a learning testbed for dependency injection through dagger 2. However, building the package using maven-2 cmd:

mvn assembly:assembly -DdescriptorId=jar-with-dependencies package'. 

to generate a zip jar with the complete dependencies produces the following exception trace:

[INFO] ------------------------------------------------------------------------
[INFO] Building Echo Device Client 1.0
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ echo-device-client ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /Users/apil.tamang/Dropbox/Git/echo-device-client/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @ echo-device-client ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 46 source files to /Users/apil.tamang/Dropbox/Git/echo-device-client/target/classes
An exception has occurred in the compiler (1.8.0_60). Please file a bug at the Java Bug Database (http://bugreport.java.com/bugreport/) after checking the database for duplicates. Include your program and the following diagnostic in your report.  Thank you.
java.lang.IllegalStateException: endPosTable already set
        at com.sun.tools.javac.util.DiagnosticSource.setEndPosTable(DiagnosticSource.java:136)
        at com.sun.tools.javac.util.Log.setEndPosTable(Log.java:350)
        at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667)
        at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.<init>(JavacProcessingEnvironment.java:892)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.next(JavacProcessingEnvironment.java:921)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1187)
        at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
        at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
        at com.sun.tools.javac.main.Main.compile(Main.java:523)
        at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
        at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)

The initial compilation happens fine, and all tests are run and successfully executed. I feel like it is during 'linking' the dependencies that things go south. Please take a look at this file to see the console output during the build.

My question is if it's worth a shot to try generate the dependencies using a different way. I don't know much about maven for that purpose. Is there a patch or something out there that can be used? Do you think it's even possible to come up with a workaround? I would like to be able to continue to use the dagger 2 framework for building this project.

回答1:

The issue is described in the bug report JDK-8067747:

(by Jan Lahoda)

To my knowledge, there are two aspects to this bug:

1. the javac bug that it crashes with an exception. I am working on this, but please note that javac won't compile the input when this is fixed, it will throw an appropriate exception from the Filer (see below).

2. what appears to be a maven bug: when the project is compiled with "clean install", an annotation processor will generate a source file into "target/generated-sources/annotations". When the incremental compilation is done, this generated file is passed to javac as an input, and the annotation processor will try to generate it again, which is not allowed.

This implies that when the maven bug is fixed, javac’s bug of reporting the problem with an inappropriate exception becomes irrelevant. However, given the actual date of Maven 2’s end-of-life, I doubt that you can expect to find a fix or patch for it.

回答2:

As explained in this issue, a workaround is to disable useIncrementalCompilation:

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>

    <configuration>
        <useIncrementalCompilation>false</useIncrementalCompilation>
    </configuration>
</plugin>

回答3:

I'm not sure if this can help. For my case, I had the same problem with open-jdk 8u91, I installed oracle-jdk and I could run the project after mvn clean compile. The problem was I must switched between JDKs for each run and building it once again with maven.

EDIT: after struggling about two days with it I found it is a result of mismatch between maven and jdk. My IDE used maven 3.0.5 as bundled maven.

Solution: In your IDE you should change your maven home directory from bundled maven to your current version for example /usr/share/maven. ( for me current version was 3.3.9)

回答4:

I have encountered the same error with a project that was built and tested by Maven and JDK 1.8.0_121. In the original configuration the project was first cleaned via mvn clean, then built using mvn install -projectSpecificParameters and finally tested with a separate mvn install -otherProjectSpecificParameters. This configuration resulted in the error mentioned in the question.

After changing the order of the stages (first testing and then building) and adding a clean goal to the build command to clean up the built state after the tests the error was not reproducible anymore.