JDK-6403465 : javac should defer diagnostics until it can be determined they are persistent
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2006-03-24
  • Updated: 2011-04-21
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b112Fixed
Related Reports
Duplicate :  
JDK-6911972 - "cannot find symbol" errors for classes which are about to be generated by an AP
Duplicate :  
JDK-6727243 - Duplicate Errors message when compiling with "javac -processor"
Relates :  
JDK-6432333 - APT fails to gracefully handle errors
Relates :  
JDK-5060009 - Tidy up the case where a superclass is generated by apt
Relates :  
JDK-7141956 - Java 7 compiler performance degradation
Relates :  
JDK-6724071 - refactor Log into a front end and back end
Relates :  
JDK-7001389 - testNegativeModelWithSystemCompiler test fails in org.eclipse.jdt.compiler.apt.tests package
Relates :  
JDK-6976747 - JCDiagnostic: replace "boolean mandatory" with new "Set"
Relates :  
JDK-5052910 - need option to turn javac errors into apt errors
Relates :  
JDK-6969184 - poor error recovery after symbol not found
Description
Currently, javac will report diagnostics, either in the default manner or via a DiagnosticListener, even if those errors are effectively transient errors that will go away on subsequent processing rounds.

javac should buffer and defer such diagnostics until it can be determined whether they should be suppressed or not.
.
.
From experience with apt, various others requests have come in for improved error handling of various sorts:

5052910 need option to turn javac errors into apt errors
Fail-fast if any error compilation error is found.

6432333 APT fails to gracefully handle errors
Request to fail-fast or return a more useful annotation type for a malformed annotation.
Comments
EVALUATION Unfortunately, AbstractLog does not help since you cannot install an alternative Log impl in time. Therefore the buffering has to be done inside the existing Log impl. Then, the next step is a change in strategy. Rather than identifying unrecoverable errors, identify the recoverable errors instead -- i.e. the errors that can arise from missing symbols, which might be fixed after a round of annotation processing. These errors are all generated via Resolve.logResolveError, so that gives a convenient place to tag all recoverable errors. The final step is to change JavacProcessingEnvironment.Round.unrecoverableError to check whether any conditions have arisen which should stop annotation processing -- these include errors reported by the messager, any warnings if -Werror is set, and any javac errors that did not come from Resolve.logResolveError.
23-08-2010
EVALUATION This is made easier by the recent refactoring of Log into AbstractLog and Log 6724071
24-07-2008
EVALUATION Quality of implementation issue for annotation processing.
31-03-2006