[news.eclipse.tools.jdt] Re: Question on Marker use (APT vs. JavaModel)

["Walter Harley" <wharley@xxxxxxx>]

"Mike Yawn" <myawn@xxxxxxxx> wrote in message 
news:46FAE32F.9050108@xxxxxxxxxxx
> Coming back into this after some time -- this is working great for the 
> case where the user modifies the file and then saves it.  But if the user 
> has unsaved changes that result in problems, there problems are visible in 
> the editor, but are not seen in either the Problems view or via the 
> IResource.findMarkers() API.

And earlier:

> This works fine in the context of the Annotation Processor and Quick fix 
> processors.  However, now i have a need to have these errors be visible 
> outside of annotation processing (specifically, I want to enable/disable 
> particular actions based on whether there are annotation errors).


"Whether there are annotation errors" is ambiguous; there could be an error 
in saved code and not in unsaved edited code, or vice versa.  If you build 
with unsaved changes, the build (and the input to the annotation processor) 
reflects what's on disk, not what's in the editor.  Which state should your 
UI reflect?  The saved code, or the latest edits?  You might want to 
consider other examples - perhaps there's something in the refactoring 
menus, which would have similar issues.

When you make edits but don't save a file, the temporary in-memory image is 
represented as a "working copy", owned by the editor (in this case the JDT 
Text component).  Problems reported during compilation (and annotation 
processing) of that working copy show up only for the working copy owner, 
that is, the editor; or not, depending on the preferences of the working 
copy owner.  Basically when the owner says "reconcile this", it can pass in 
a ProblemRequestor that will be notified of any problems; or it can pass in 
null to ignore problems.

So, the behavior of errors in unsaved code appearing in the editor but not 
in the problems pane is by design.  It's what supports things like letting 
you see "what errors would occur" during a refactoring operation.

I'm not sure exactly how you can recover the errors reported to the Java 
editor as it reconciles, but I expect that one way or another they need to 
come from the working copy owner's problem requestor.  Or another approach 
is to get the editor's text, create a working copy of your own, and 
reconcile that working copy using your own ProblemRequestor.  This might run 
into issues if there are multiple files with unsaved changes (i.e., would 
you get all the changed files, or only the one you grabbed); the answer 
might be to act as the default working copy owner (same as the Java editor). 
Sorry to be vague about this - I am not very solid in my knowledge of the 
Java editor and how it manages working copies.

As a sidebar, editing the declaration of an annotation, or of a base class, 
could also in principle cause an annotation processor to report an error. 
Also, the Java model seen by the annotation processor if you do a build 
while there are unsaved changes can have some inconsistencies, because of 
the mix of working copies versus files on disk.  These are complex topics 
and I don't want to get into the ramifications here, but it's something to 
think about.

  -Walter Harley
   JDT APT team