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

[Mike Yawn <myawn@xxxxxxxx>]

Thanks so much for taking the time to write up this explanation -- it 
really helps me make sense of some of the underlying reasons for why 
some things are working the way they do.

I'll do some investigation around the ProblemRequestor -- but at the 
same time, I'm going to discuss with other team members whether this is 
really the right approach to be taking in this whole area.

Mike

Walter Harley wrote:
> "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