AssertionError in c.s.t.jc.comp.Modules.enter(..)
Eirik Bjørsnøs
eirbjo at gmail.com
Tue Dec 13 10:22:11 UTC 2016
Jan,
I've been able to reproduce this in a J9 branch of Reststop (an open
source). Here's a Github repo with a script to reproduce:
https://github.com/eirbjo/javac-assertionerror-reproducer
Observations:
* The AssertionError happens _without_ --add-modules java.xml.bind. With
--add-modules, there are no compilation errors
* There are in total 6 Diagnostic instances, each ERRORs for missing
java.xml.bind types in ConfDocMojo.java
* The particular one causing the AssertionError is a
"cant.resolve.location" for JAXBContext from the following line:
private Map<String, List<PluginConfig>> findConfigs(JAXBContext context)
throws MojoFailureException, MojoExecutionException, JAXBException,
IOException {
* Calling getMessage on the Diagnostic only fails the first time. Calling
it a second time (from a debugger) does not cause an AssertionError.
* When Assert.check in Modules.enter() fails, the variables are:
rootModules: null, inInitModules: false, allowModules: true
Why is rootModules null in this case?
Cheers,
Eirik.
On Mon, Dec 12, 2016 at 2:35 PM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> Hi Eirik,
>
> A reproducible test case would be ideal, but I have a few questions for
> now: does the build (without --add-modules java.xml.bind) produce any
> error/warnings? I assume the build does not crash with the AssertionError
> when doing a clean build, right? Any idea on what the diagnostics on which
> the compilation crashes could be? What version of the compiler plugin do
> you use?
>
> Thanks!
> Jan
>
>
> On 11.12.2016 20:12, Eirik Bjørsnøs wrote:
>
>>
>> Hi,
>>
>> I'm getting the following AssertionError from javac: (Full stacktrace at
>> end of email)
>>
>> Exception in thread "main" java.lang.AssertionError
>> at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>> at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>> at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:243)
>>
>>
>> I wanted to reduce this to a minimal testcase, but after two hours
>> when I thought I'd finally nailed it, I did an mvn clean somewhere and
>> now I can't reproduce it :-)
>>
>> So what we have to work with is unfortunately my anecdotal observations:
>> (Can't share the full mvn build..)
>>
>> * This is maven-compiler-plugin compiling via plexus-compiler via
>> javax.tools.JavaCompiler
>> * The AssertionError happens when calling diagnostic.getMessage(Locale)
>> * Source file being compiled imports a class from a jar on the classpath
>> which again imports from java.xml.bind
>> * java.xml.bind is _not_ added with --add-modules-path
>> * When I add --add-modules-path=java.xml.bind to the CompilationTask's
>> options, the AssetionError is no longer thrown
>> * When I remove a jar containing a
>> javax.annotation.proccessing.Processor from the -classpath, the
>> AssertionError was no longer thrown
>>
>> While my immediate problem is solved using --add-modules, I'm assuming
>> this AssertionError is something which should/could be fixed?
>>
>> I'll try a bit more to create a minimal test case, but wanted to share
>> my observations anyway, since compiler internal wizards might spot
>> what's going on just from this.
>>
>> Sorry that this report is a bit messy, it was the best I could do this
>> time.
>>
>> Let me know if there's more useful info I can provide.
>>
>> Cheers,
>> Eirik.
>>
>>
>>
>> Full stacktrace:
>>
>> Exception in thread "main" java.lang.AssertionError
>> at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>> at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>> at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:243)
>> at
>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourc
>> eFile(JavaCompiler.java:841)
>> at
>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourc
>> eFile(JavaCompiler.java:821)
>> at
>> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingE
>> nvironment$ImplicitCompleter.complete(JavacProcessingEnviro
>> nment.java:1469)
>> at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633)
>> at
>> jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.com
>> plete(Symbol.java:1273)
>> at
>> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.complet
>> e(Type.java:1150)
>> at
>> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.getType
>> Arguments(Type.java:1076)
>> at
>> jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType
>> (Printer.java:237)
>> at
>> jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType
>> (Printer.java:52)
>> at
>> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(
>> Type.java:1003)
>> at jdk.compiler/com.sun.tools.javac.code.Printer.visit(Printer.java:136)
>> at
>> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticForm
>> atter.formatArgument(AbstractDiagnosticFormatter.java:197)
>> at
>> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticForm
>> atter.formatArguments(AbstractDiagnosticFormatter.java:165)
>> at
>> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatt
>> er.formatMessage(BasicDiagnosticFormatter.java:111)
>> at
>> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatt
>> er.formatMessage(BasicDiagnosticFormatter.java:67)
>> at
>> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticForm
>> atter.formatArgument(AbstractDiagnosticFormatter.java:183)
>> at
>> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticForm
>> atter.formatArguments(AbstractDiagnosticFormatter.java:165)
>> at
>> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatt
>> er.formatMessage(BasicDiagnosticFormatter.java:111)
>> at
>> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatt
>> er.formatMessage(BasicDiagnosticFormatter.java:67)
>> at
>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.getMessag
>> e(JCDiagnostic.java:775)
>> at
>> jdk.compiler/com.sun.tools.javac.api.ClientCodeWrapper$Diagn
>> osticSourceUnwrapper.getMessage(ClientCodeWrapper.java:788)
>> at
>> org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compil
>> eInProcess(JavaxToolsCompiler.java:131)
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161213/2a0abce4/attachment.html>
More information about the compiler-dev
mailing list