Bug ID: JDK-6278226 Compiler errors in source code don't always cause apt programmatic interface to return non zero

Type: Bug
Component: tools
Sub-Component: apt
Affected Version: 6

Priority: P3
Status: Closed
Resolution: Duplicate
OS: windows_2000
CPU: x86

Submitted: 2005-05-31
Updated: 2017-05-16
Resolved: 2009-09-22

J2SE Version (please include all output from java -version flag):
  java version "1.5.0_03"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
  Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing)
  and 
  java version "1.6.0-ea"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b38)
  Java HotSpot(TM) Client VM (build 1.6.0-ea-b38, mixed mode)


Does this problem occur on J2SE 1.3.x or 1.4.x?  Yes / No (pick one)
  N/A

Operating System Configuration Information (be specific):
  Win 2K

Bug Description:
  Compiler errors in source code don't always cause apt programmatic interface 
  to return non zero.

  With an annotation which doesn't match a bound wildcard for a class type element.

  The compiler phase generates an error, then runs an apt processor. If the
  processor does not generate any error messages or source, and the -nocompile
  option is specified, the programmatic interface returns with a result of 0, 
  when in fact there are errors in the code and 1 should be returned.

Steps to Reproduce (be specific):
  in same directory as attached source files

  javac -cp "%JAVA_HOME%\lib\tools.jar" SomeProcessor.java Programatic.java
  java -cp .;"%JAVA_HOME%\lib\tools.jar" Programatic

  prints "result code = 0" expected "result code = 1"













###@###.### 2005-05-31 15:52:12 GMT

EVALUATION Duplicate of 4991798; closing accordingly.

22-09-2009

EVALUATION The apt command uses the javac infrastructure to parse and analyze the input programs. From apt's perspective, there are two kinds of errors javac could report, errors that could be corrected by an annotation processor generating new source code (e.g. a class that needs its superclass to be generated) and errors that could not be corrected by addition code being generated (e.g. parsing errors). Apt was required to be able to operate on partially complete source code, e.g. types without superclasses; as the javac infrastruture did not provide a ready way to discriminate between the two kinds of errors, during the non-compilation portion of annotation processing, apt ignores all javac errors. Ideally, apt would only ignore errors that could be possibly be corrected by generation of new source code. By default, the final compile done by apt will catch and report all such errors in the entire code base in question. However, if the -nocompile option is used and ompilation is thus suppressed, apt will not report errors on the code being processed, as noted in this bug. An approximate fix to this bug would be to have better integration with javac to allow apt report an error and stop processing if a parsing error was found regardless of whether or not -nocompile is used. This would still omit reporting typing errors; however, you don't really know if a typing error was corrected until the code is analyzed again in the context of any newly generated source and class files. (The source files mentioned in the description don't seem to be attached to this bug so I don't know if syntax errors or typing errors or both prompted the bug report.) ###@###.### 2005-06-15 22:52:07 GMT

15-06-2005

Duplicate :	JDK-4991798 - need some indications of errors/warnings when running -nocompile
Relates :	JDK-5038056 - apt must be able to operate on incomplete source files
Relates :	JDK-5052910 - need option to turn javac errors into apt errors
Relates :	JDK-6403459 - JavacProcessingEnvironment should know if parser errors occurred
Relates :	JDK-6378728 - -proc:only generates classes if no processors found