Description Walter Harley 2007-02-02 19:46:09 EST

(per discussion with Olivier)

The AbstractAnnotationProcessorManager interface tells the Compiler about new units via the method 
  ICompilationUnit[] getNewUnits()

The ICompilationUnit type here is in org.eclipse.jdt.internal.compiler.env; it is not the same as the Java Model type of the same name.  In order to implement this method, the AnnotationProcessorManager needs to be able to create objects that implement this interface.

In batch mode, it simply constructs an org.eclipse.jdt.internal.compiler.batch.CompilationUnit.

In IDE mode, the necessary implementation of ICompilationUnit seems to be org.eclipse.jdt.internal.core.builder.SourceFile.  (When I tried passing in a CompilationUnit, I got ClassCastException from something casting it to a SourceFile.)  But it seems that the only way to get a SourceFile is to call AbstractImageBuilder.findSourceFile().  The constructor of SourceFile requires a ClasspathMultiDirectory, which is a package-access object, so I can't directly construct one from within APT.

If I am right about that, the least fragile way I can see for APT to create an ICompilationUnit in IDE mode is to add an interface in jdt.core like the following, have AbstractImageBuilder implement it, and pass it in as a parameter to
AbstractAnnotationProcessorManager.configureFromPlatform():


  public interface ICompilationUnitLocator {
    public ICompilationUnit fromIFile(IFile file);
  }

  // Method in AbstractAnnotationProcessorManager:
  public abstract void configureFromPlatform(
      Compiler compiler, 
      Object compilationUnitLocator, 
      Object javaProject);


Are there any other approaches that might be cleaner or simpler?  I considered just passing the AbstractImageBuilder itself, rather than an interface, but that seemed very fragile.  I also considered changing the
AbstractAnnotationProcessorManager.getNewUnits() call to return something more generic than ICompilationUnit[], but then the Compiler itself would have to figure out how to do the conversion so it wouldn't solve the problem.

I'll attach these suggestions in the form of a patch to jdt.core and a corresponding patch to jdt.compiler.apt.