Java 8 compiler error - how to get more information?

Question

I played around with Java 8 ea b72, but I get a compiler error. Is there a way to get more information from javac, e.g. the file list it is currently working on? If I had a general idea where to look I might be able to find a work-around until the issue is fixed.

Just for the record, here is the stack-trace (it looks similar if compiled outside of IntelliJ IDEA, BTW):

An exception has occurred in the compiler (1.8.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.  Thank you.
java.lang.AssertionError: arraycode A
    at com.sun.tools.javac.jvm.Code.arraycode(Code.java:297)
    at com.sun.tools.javac.jvm.Gen.makeNewArray(Gen.java:1827)
    at com.sun.tools.javac.jvm.Gen.visitNewArray(Gen.java:1800)
    at com.sun.tools.javac.tree.JCTree$JCNewArray.accept(JCTree.java:1482)
    at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:893)
    at com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:912)
    at com.sun.tools.javac.jvm.Gen.visitApply(Gen.java:1746)
    at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1391)
    at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:893)
    at com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1715)
    at com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1310)
    at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:683)
    at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:718)
    at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:704)
    at com.sun.tools.javac.jvm.Gen.genStats(Gen.java:755)
    at com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1090)
    at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:835)
    at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:683)
    at com.sun.tools.javac.jvm.Gen.genStat(Gen.java:718)
    at com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:968)
    at com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:941)
    at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:723)
    at com.sun.tools.javac.jvm.Gen.genDef(Gen.java:683)
    at com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2310)
    at com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:751)
    at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1545)
    at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1509)
    at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:907)
    at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:866)
    at com.sun.tools.javac.main.Main.compile(Main.java:506)
    at com.sun.tools.javac.main.Main.compile(Main.java:365)
    at com.sun.tools.javac.main.Main.compile(Main.java:354)
    at com.sun.tools.javac.main.Main.compile(Main.java:345)
    at com.sun.tools.javac.Main.compile(Main.java:94)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:477)
    at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess0(JavacCompiler.java:551)
    at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:526)
    at org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:167)
    at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:678)
    at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:477)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
    at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:477)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)


    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:477)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
    at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:477)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)

Looks like a problem at a statement such as `return varargsMethodCall(args);` The array element type code is A, which is presumably wrong. — Marko Topolnik, Jan 15 '13 at 22:18
_file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report._ — McDowell, Jan 15 '13 at 22:21
@McDowell OP didn't miss that, if that's what you are implying. — Marko Topolnik, Jan 15 '13 at 22:22
file a bug, they would appreciate it very much. java8 is still very immature. — irreputable, Jan 15 '13 at 22:25
@MarkoTopolnik I was being facetious, but searching the bug reports in cases like this is not unreasonable (or at least saying that you couldn't find a matching case, or including more details about the code in question.) — McDowell, Jan 15 '13 at 22:27
@McDowell The way I understand it, the problem seems to be that the OP doesn't even know which file/class is being compiled when the compiler throws. It's probably not massively useful to submit a bug report without any code or with a folder with 50k lines of code. — us2012, Jan 15 '13 at 22:29
@McDowell But OP's desire to find out about his problem to be able to work around it is fully legitimate. — Marko Topolnik, Jan 15 '13 at 22:29
@us2012 Understood, but this is an assumption on your part - there is no context in the question about how this error came about. A large Java 7 codebase? A simple demo? Who knows. _"I played around"..._ — McDowell, Jan 15 '13 at 22:33
@McDowell The code is a Java8 port and extension of http://code.google.com/p/highj/ - which means 50+ classes with really ugly generics. At least I *tried* to file one (heck, I even tried to send it to the mailing list), but couldn't find later - maybe because the available options made not much sense. The infrastructure behind Java 8 development seems to be quite opaque and fragile right now, and I think Oracle needs to do a better job if they expect more feedback from the EA program. — Landei, Jan 16 '13 at 08:23
@Landei I have had many compiling issues with existing project with a recent build. It is still very messy. Hopefully the next milestone at the end of January will produce a fairly usable release. — assylias, Jan 18 '13 at 12:08
The problem were not the vararg methods themselves, but calling such a method, most likely from a lamba. I don't know which one exactly, though: First I changed all vararg methods to arrays and fixed all code calling them. Then I found out I could put all varargs back in place, and it was still running. — Landei, Feb 10 '13 at 20:09
In my Experience, this problem happens when you not properly override class functions (For example, create a method called getClass() not overriding the original one, but returning an internal String property) — Jav_1, Jun 08 '20 at 17:04

score 3 · Answer 1 · answered Jan 23 '13 at 19:29

3

This is a bit of a last-resort, but you could try using strace to monitor what files javac is opening. strace [your javac invocation] | grep '/directory/you/are/interested/in/ might give you some clues.

answered Jan 23 '13 at 19:29

jacobm

13,790
1
25
27

Good idea. If this is on Windows, [Process Monitor](http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) could also help narrow down which files are being accessed in a similar vein. – John McCarthy Jan 24 '13 at 03:57

score 2 · Accepted Answer · answered Jan 24 '13 at 05:05

Have you tried javac's -verbose flag? A simple ant script such as the following could be used to enable verbose compiler output,

<project name="verbose_compile" default="compile" basedir=".">
  ...
  <target name="compile">
      <javac srcdir="${src.dir}" 
         destdir="${build.dir}"
         executable="${java8.home}/bin/javac" 
         classpath="..."
         fork="true" 
         verbose="true" />
  </target>
</project>

(Looks like user property maven.compiler.verbose would accomplish the same thing in maven.)

I just ran into a similar situation. On Windows, the verbose output showed me the class being compiled just before the error. Hopefully that will help you narrow down the problem for a workaround.

score 0 · Answer 3 · answered Jan 24 '13 at 06:27

This is not the solution for your problem. May be you can figure out what could have gone wrong with this.

Below is the method where "AssertionError" is thrown.

/** Given a type, return its code for allocating arrays of that type.
*/
public static int arraycode(Type type)
{
    switch (type.tag)
    {
        case BYTE: return 8;
        case BOOLEAN: return 4;
        case SHORT: return 9;
        case CHAR: return 5;
        case INT: return 10;
        case LONG: return 11;
        case FLOAT: return 6;
        case DOUBLE: return 7;
        case CLASS: return 0;
        case ARRAY: return 1;
        default: throw new AssertionError("arraycode " + type);
    }
}

You can find the com.sun.tools.javac.jvm.Code class implementation here (I could not find the correct version of this class though, as in this class error is thrown at line 298 and in your case it is at 297). It might help.

I found link, Bug ID = 4901611, showing similar bug in previous release of Java. Version is Java 1.5. In this link you will find that this kind of error occurs when "generic method with vararg" gets unexpected input resulting in AssertionError. No workaround given and it was fixed in next update :(

Java 8 compiler error - how to get more information?

3 Answers3