Summary: | DiagnosticListener always supplies Diagnostic.getSource()==null | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | bugzilla.20.htowninsomniac | ||||
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | jarthana, Olivier_Thomann | ||||
Version: | 3.6 | ||||||
Target Milestone: | 3.6 M7 | ||||||
Hardware: | PC | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
bugzilla.20.htowninsomniac
2010-04-06 14:36:10 EDT
I cannot simply use getJavaFileObjects(..) since the file manager is supposed to be a JavaFileManager and not a StandardJavaFileManager. Using the actual argument I have no way I can get the appropriate package name. I'll see what I can do. The IProblemFactory is Eclipse's interface and not part of JSR199, I believe. You should be able to change the createProblem methods to also include the full class name, or perhaps even the JavaFileObject directly. The compiler should have that information. Created attachment 164109 [details]
Proposed fix
Even if I would pass the package name or the class name, I might still not be able to open the right file if the source contains a package, but is compiled from a folder that doesn't contain a subfolder corresponding to the package name.
So I suggest to simply create a EclipseFileObject instance based on the full path name for the originating file. So I shortcut the usage of the file manager in this case.
I might revisit the fix post 3.6. At least simple cases will be handled now.
I'll try to see how javac is handling the case above.
javac doesn't seem to go through the file manager to create the source java file object. So I'll release this code. Verified for 3.6M7 by code inspection and unit tests. |