Community
Participate
Working Groups
Build Identifier: ecj-3.6M6.jar When compiling with a DiagnosticListener and encountering an error, the provided Diagnostic<JavaFileObject> always returns null for the getSource() call. This is because originatingFileName is being passed to JavaFileManager.getJavaFileForInput, even though the method expects a class name. For example, "/home/username/temp/Foo.java" is being passed as a class name, not "Foo". @Override public JavaFileObject getSource() { try { if (EclipseCompilerImpl.this.fileManager.hasLocation(StandardLocation.SOURCE_PATH)) { return EclipseCompilerImpl.this.fileManager.getJavaFileForInput( StandardLocation.SOURCE_PATH, new String(originatingFileName), JavaFileObject.Kind.SOURCE); } } catch (IOException e) { // ignore } return null; } Instead of using getJavaFileForInput, which expects a class name, you could use getJavaFileObjects, which works for a file name. Reproducible: Always Steps to Reproduce: 1. Just compile code using a DiagnosticListener 2. Encounter an error in a Java file. 3. Look at the return value of Diagnostic.getSource(), it is always null.
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.
