Bug 361181

Description Tom Ball 2011-10-17 15:40:27 EDT

Build Identifier: I20110613-1736

When a package has a package-info.java file, calling ASTParser.createAST() with the source for a class with an inner type causes the package's compilation unit to be returned.  ASTView shows this problem, though we're experiencing it in our own tool (so ASTView isn't to blame).

For example, the com.google.common.base package in the Guava Library has a package-info.java file.  Its Strings.java file returns the correct compilation unit, but Objects.java returns the package-info's unit.

This appears to be due to CompilationUnitResolver.resolve at line 1126:

// process all units (some more could be injected in the loop by the lookup environment)
unit = this.unitsToProcess[0];

Strings.java's unitsToProcess is [Strings, pkg-info], while Objects.java's is [pkg-info, Strings].


Reproducible: Always

Steps to Reproduce:
1.  Download Guava using "git clone http://code.google.com/p/guava-libraries/source/checkout"
2.  In Eclipse, import maven projects, importing the guava and guava-bootstrap projects.
3.  Edit guava's pom.xml, deleting the maven-dependency-plugin artifactId section.
4.  Change the project's JDK compliance level to 1.6, to clear the remaining build errors.
5.  Open Objects.java in com.google.common.base, and view it using ASTView.

Note how the types list is empty, and the package has an annotation -- that's because the returned unit from ASTParser.createAST() returned the package-info.java unit.

6. Open Strings.java in the same package, and refresh the ASTView.

Note how the types list has an element, and the package doesn't have an annotation -- we got the correct compilation unit.