Fixing JDK-8130493
Schaef, Martin
schaef at amazon.com
Tue Jan 9 17:52:53 UTC 2018
Hi,
We have some users suffering from JDK-8130493<https://bugs.openjdk.java.net/browse/JDK-8130493> (their builds succeed, but the compiler actually failed). I did some digging and the following sequence happens:
A ClassNotFoundException is thrown in JavaProcessingEnvironment.ServiceIterator.next()<http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/file/989188d1a978/src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java#l364> and re-thrown as an Abort.
This Abort reaches JavaCompiler.processAnnotations()<http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/file/989188d1a978/src/share/classes/com/sun/tools/javac/main/JavaCompiler.java#l1170> and is finally caught in JavaCompiler.compile()<http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/file/989188d1a978/src/share/classes/com/sun/tools/javac/main/JavaCompiler.java#l856> by the following snippet:
try {
initProcessAnnotations(processors);
// These method calls must be chained to avoid memory leaks
delegateCompiler =
processAnnotations( //<<<<<< ABORT COMES OUT HERE
enterTrees(stopIfError(CompileState.PARSE, parseFiles(sourceFileObjects))),
classnames);
…
} catch (Abort ex) {
if (devVerbose)
ex.printStackTrace(System.err);
} finally {
and swallowed ... but it's printed if XDev is set.
What is a proper way to fix this? Is it correct to wrap all exceptions in JavaProcessingEnvironmentServiceIterator into aborts? Or would it be better to distinguish different Aborts in JavaCompiler.java?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180109/be0a07b6/attachment.html>
More information about the compiler-dev
mailing list