I've managed to write some code that causes an error during compilation using JDK 1.8.0_131 due to a JDK bug. I can reproduce the issue with only a few lines of code—but I can't find where in my project the error-causing pattern is being used.
My goal is to figure out which code in my project is causing this bug, and apply a workaround.
The issue is outlined in the JDK-8074381 bug report and can be replicated in only a few lines of code.
public class Test {
public interface Foo<L> extends Function<Number, String> {
String apply(Number p);
}
private static final Foo CRASH = p -> "This will crash javac 1.8.0_131";
}
The issue manifests when using non-parameterized lambda instead of a non-parameterized inner class (which should both be valid according to the language spec I believe). So
private static final Foo INNER = new Foo<Object>() {
@Override
public String apply(final Number p) {
return "This will not crash javac 1.8.0_131";
}
};
works fine. The offending stack trace begins (truncated for your sanity):
An exception has occurred in the compiler (1.8.0_131). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you.
java.lang.AssertionError
at com.sun.tools.javac.util.Assert.error(Assert.java:126)
at com.sun.tools.javac.util.Assert.check(Assert.java:45)
at com.sun.tools.javac.code.Types.functionalInterfaceBridges(Types.java:659)
at com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor$TranslationContext.<init>(LambdaToMethod.java:1770)
at com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor$LambdaTranslationContext.<init>(LambdaToMethod.java:1853)
at com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor.analyzeLambda(LambdaToMethod.java:1337)
at com.sun.tools.javac.comp.LambdaToMethod$LambdaAnalyzerPreprocessor.visitLambda(LambdaToMethod.java:1322)
at com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:1624)
at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
at com.sun.tools.javac.tree.TreeTranslator.visitVarDef(TreeTranslator.java:153)
I'm aware that this issue is fixed in JDK9, however this project requires that I use JDK 8.
So rather than updating to JDK9, I need to figure out which code in this project is producing the error. Here's what I've tried.
My first thought was to inspect the file that was being compiled when this error occurred. However, I'm unable to figure out how to check which source file was being compiled when the error was encountered. If this is possible, that information would be helpful.
My second thought was to do a regex search of all of my code to look for any type parameterized interfaces or interfaces that extend generic interfaces. Neither of these searches yielded code which obviously matches the issue producing code—no unused generics (changing interface Foo<L>
to interface Foo
in the example would fix the issue). Therefore I think that a more subtle understanding of what inside of the compiler actually causes this bug might be helpful in identifying the piece of code responsible, because it might widen my search criteria. (It's also possible that I'm getting a bug with the exact same stack trace for a completeley different problem, but this seems unlikely to me and I'm not sure where I'd start on that, any ideas?)
I think it would be most worthwhile to be able to inspect a compiler log or something to check what was being compiled when this issue popped up. Any ideas?
Thanks.
If the brackets don't all match up, the result is a compile time error. The fix to this compile error is to add a leading round bracket after the println to make the error go away: int x = 10; System.
During compilation, the compiler has no technique to detect these kinds of errors. It is the JVM (Java Virtual Machine) that detects it while the program is running. To handle the error during the run time we can put our error code inside the try block and catch the error inside the catch block.
Instead, if an error does occur, your program can inform the user in a much more user-friendly manner, and you can still retain control over the program. Debugging , on the other hand, involves finding errors and removing them from your program.
I noticed that the bug report has a .out
file that has the class information. The first point of reference is to follow the How to file a JDK Bug Report.
The javac
command has a -verbose
option. I tried it using the class of the bug report and it wrote this output:
javac Lib.java -verbose
[parsing started RegularFileObject[Lib.java]]
[parsing completed 26ms]
[search path for source files: .]
[search path for class files: /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/resources.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/rt.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/sunrsasign.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/jsse.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/jce.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/charsets.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/jfr.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/classes,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext/cldrdata.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext/dnsns.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext/jaccess.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext/jfxrt.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext/localedata.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext/nashorn.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext/sunec.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar,/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext/zipfs.jar,/System/Library/Java/Extensions/AppleScriptEngine.jar,/System/Library/Java/Extensions/dns_sd.jar,/System/Library/Java/Extensions/j3daudio.jar,/System/Library/Java/Extensions/j3dcore.jar,/System/Library/Java/Extensions/j3dutils.jar,/System/Library/Java/Extensions/jai_codec.jar,/System/Library/Java/Extensions/jai_core.jar,/System/Library/Java/Extensions/mlibwrapper_jai.jar,/System/Library/Java/Extensions/MRJToolkit.jar,/System/Library/Java/Extensions/vecmath.jar,.]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/List.class)]]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/util/function/Predicate.class)]]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Object.class)]]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Class.class)]]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/SuppressWarnings.class)]]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/annotation/Annotation.class)]]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/String.class)]]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/annotation/Target.class)]]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/annotation/ElementType.class)]]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/annotation/Retention.class)]]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/annotation/RetentionPolicy.class)]]
[checking Lib]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/io/Serializable.class)]]
[loading ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/AutoCloseable.class)]]
An exception has occurred in the compiler (1.8.0_92). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you.
java.lang.AssertionError
Given that it printed out Checking Lib and failed while compiling it makes it a useful tool to find out the source files. So you should be able to compile your project in verbose mode and it will fail on the first instance of this error (I think)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With