JDK-6973626 : test/tools/javac/processing/* tests fail with assertions enabled
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-07-30
  • Updated: 2011-05-18
  • Resolved: 2011-05-18
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 b105Fixed
Related Reports
Relates :  
JDK-6966604 - JavacFiler not correctly notified of lastRound
Description
41 tests of out 58 fail run using jtreg -ea:com.sun.tools.javac... to run test/tools/javac/processing tests.
Comments
EVALUATION noreg-other since fix covered by existing tests when run with assertions enabled.
02-08-2010
EVALUATION The assertion that is failing was added as part of 6966604, which refactored the doProcessing loop. However, the issue that is triggering the assertion is a latent bug in the original code which survived the refactoring. In the original code, pre-6966604, the issue is as follows. -- In the last round in which there are topLevelClasses and annotationsPresent, the processing is done in the currentContext, by discoverAndRunProcs on line 846. Then, shortly afterwards, moreToDo() returns false, on line 862, leading to "break runAround;" on line 906. The code then drops into runLastRound on line 909, using the same compiler as was used for the previous round of processing. There is no issue with an assertion because (a) there is no assertion (!) and (b) runLastRound is handled differently to previous rounds and explicitly sets topLevelClasses and annotationsPresent to empty lists. However, the issue remains that the code was questionably reusing the compiler for the last round instead of creating a new one. [[ However, it also turns out it was not too much of a big deal because only the parser was reused. ]] -- In the new code, post-6966604, the logic that didn't create a new compiler in the old code was translated to logic that doesn't create a new Round object in the new code. As a result, because the Round object was being reused, the values for topLevelClasses and annotationsPresent were left set to the values for the preceding round, instead of being reset to empty lists as would have happened if a new Round object has been created.
30-07-2010