How to access the *.java file corresponding to a TypeElement T?

Question

Here is a problem:
How to access the *.java file corresponding to a TypeElement T from a AnnotationProcessor environment?
Let us say the hook method
public boolean process(Set<? extends TypeElement> annos, RoundEnvironment roundEnv)
is invoked with a TypeElement T such that T.getQualifiedname() = "a.b.c.X"
And the problem is how to locate the file that has the *.java source code for a.b.c.X?
That is the file that has the source code for a.b.c.X say "some/path/a/b/c/X.java"?
For simplicity, let us assume that TypeElement T corresponds to a top-level Java class.

Answer 1

Pinaki wrote:
That is not something you as the annotation processor author should be asking about. That is something you the person configuring the javac environment should set up via the -d option or its equivalent.
I strongly recommend using a separate output directory hierarchy.That is the way the current implementation is. The annotation processor takes a -Aout= <some directory path> to write generated output relative to a user-specified location (which defaults to the class output location).That is contrary to the design of the annotation processing facility. The intended use is for that information to be configured via options like "javac -d".
Additionally, IMO it is a serious configuration error to put generated files and input files, presumably tracked under version control, in the same directory. Interesting you said that. We are just running some "field trial" with these things and some users want them to be in the same directory of the original *.java files (especially when their source files are spread across many roots) .
Who knows what the user wants?The user does and the user is free to (mis)configure their environment however they like ;-) However, that is the user's option and the user has control of this via the javac command line. The annotation processor is not the proper place to configure this setting; see slide 7 of http://blogs.sun.com/darcy/resource/J1_2006-BOF-0606.pdf for some thoughts on different roles in annotation processing.
presumably tracked under version control, in the same directory.version control is another 'usability issues' that we are trying to get our heads around with this stuff. "To check-in or not?" - that seems to be the question. When presented these facilities without any cue, "the users" were divided -- some wanted them to be checked-in, some did not. The context where these generated files being used -- there exists some rationale to check them in a version control system.The right answer depends on the circumstances, but IMO generally generated files should not be checked in under version control, especially if they are derived from other source files. Checking in generated files of this nature just creates the opportunity for them to get out of date with the originating files.