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