[NEW_BUG] javac fails and exits with no error if a bad annotation processor is on the classpath

Jonathan Gibbons jonathan.gibbons at oracle.com
Thu Jan 31 16:56:08 UTC 2019


Steve,

When you post the new webrevs, can I suggest that you change the Subject 
line of this thread to something like

RFR: 8218152 [javac] fails and exits with no error if a bad annotation 
processor provided

That will help get attention from reviewers, and help any subsequent 
bug-archaeology.

I can sponsor the changes for you once they have been reviewed.

-- Jon

On 1/31/19 8:49 AM, Steve Groeger wrote:
> Hi Jonathan,
>
> Thanks for responding.
>
> I have created a couple of webrevs for jdk8u [1] and jdk [2] which 
> also include some JTReg tests.
> I would be grateful if you, or someone else could review these just to 
> ensure I am doing the right thing.
> I will update the code with the additional 'throw FatalError' that you 
> mentioned and will then create some new webrevs
>
> If you are able to sponsor these changes for me I would be very grateful.
>
> PS. As you saw I have created a JBS issue for this here [3]
>
> [1] http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.00/
> [2] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.00/
> [3https://bugs.openjdk.java.net/browse/JDK-8218152
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groeges at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU
>
>
>
> From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
> To: Steve Groeger <GROEGES at uk.ibm.com>, compiler-dev at openjdk.java.net
> Date: 31/01/2019 16:33
> Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad 
> annotation processor is on the classpath
> ------------------------------------------------------------------------
>
>
>
> Steve,
>
> Your fix is generally good: Abort should only be used after a suitable 
> message has been reported.
>
> There's a `catch (Throwable t)` in the same set of catch blocks that 
> you did not update. Rather than add yet another message for that case, 
> it might be better to throw FatalError, to provoke the standard "javac 
> crash" output for the unknown exception.
>
> You should provide a test case ... i.e. as a jtreg test.
>
> -- Jon
>
> On 1/29/19 3:18 AM, Steve Groeger wrote:
> Hi all,
>
> I have identified a potential issue where javac fails and exits with 
> no error if a bad annotation processor is on the classpath.
>
> Background: an Annotation Processor class can be packaged in a jar 
> file and is identified by a special text file inside the jar named: 
> META-INF/services/javax.annotation.processing.Processor. This text 
> file has only one line, specifying the class name of the annotation 
> process class to run. When javac runs, it checks all jars on the 
> classpath and if it finds the special text file in any jar file, then 
> it attempts to run the class listed there.
>
> The issue here is that when the annotation processor class can't be 
> executed, javac catches the exception and exits without reporting on 
> the reason for the exit. Examples of reasons why the annotation 
> processor can't be executed include:
>
>   * the annotation processor class is compiled for a higher version of
>     Java than the javac is running, giving UnsupportedClassVersionError.
>   * the annotation processor class file is corrupt so can't be loaded.
>
>
> In either of the above cases javac will swallow the error and exit 
> without telling the user why it failed to compile the java source code 
> as expected.
>
> Testcase
>    put HelloWorld.java in current directory, edit <path_to_jar> and run:
>          javac -cp .:<path_to_jar>/bad.annotation.processor.jar 
> HelloWorld.java
>
> Instead of producing HelloWorld.class as expected, javac exits silently.
>
> Here, bad.annotation.processor.jar is a file that I created to contain:
>       META-INF/services/javax.annotation.processing.Processor <<-- 
> text file to list bad class
>      bad/notaclass.class <<-- dummy file, can't be loaded as a java class
>
> Does anyone know whether this is a bug and that this should throw an 
> error in these cases?
> If so, I will raise a bug for this.
>
> I have looked at the code and seen where javac Aborts the processing, 
> and if I make the following changes the javac detects the issue and 
> reports an error before Aborting.
>
> diff -r 5178e4b58b17 
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> --- 
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
>    Mon Jan 28 09:56:00 2019 +0100
> +++ 
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 
>    Tue Jan 29 11:14:57 2019 +0000
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -436,6 +436,12 @@
>              } catch(ServiceConfigurationError sce) {
>  log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
>                  throw new Abort(sce);
> +            } catch (UnsupportedClassVersionError ucve) {
> +  log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage()));
> +                throw new Abort(ucve);
> +            } catch (ClassFormatError cfe) {
> +  log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage()));
> +                throw new Abort(cfe);
>              } catch (Throwable t) {
>                  throw new Abort(t);
>              }
>
> and to add a new message there is this change
>
> diff -r 5178e4b58b17 
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> --- 
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties 
>    Mon Jan 28 09:56:00 2019 +0100
> +++ 
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties 
>    Tue Jan 29 11:16:03 2019 +0000
> @@ -1,5 +1,5 @@
>  #
> -# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights 
> reserved.
> +# Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights 
> reserved.
>  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  #
>  # This code is free software; you can redistribute it and/or modify it
> @@ -1051,6 +1051,10 @@
>  compiler.err.proc.cant.find.class=\
>      Could not find class file for ''{0}''.
>
> +# 0: string
> +compiler.err.proc.cant.load.class=\
> +    Could not load processor class file due to ''{0}''.
> +
>  # Print a client-generated error message; assumed to be localized, no 
> translation required
>  # 0: string
>  compiler.err.proc.messager=\
>
>
> If this is deemed a bug and the change seems OK, please could someone 
> sponsor this for me and I will create a proper webrev for the change 
> for a full review.
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190131/30ac1d3f/attachment-0001.html>


More information about the compiler-dev mailing list