java.lang.IllegalStateException: endPosTable already set

Question

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.

Answer 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.