Community
Participate
Working Groups
The current implementation of the compiler only supports problems which are either errors or warnings. The kinds defined in javax.tools.Diagnostic.Kind supports more possibilities which are not well mapped to actual problems. I think we should at least add the isNote() method on org.eclipse.jdt.core.compiler.IProblem to better map this kind of problems. Markers created for the problems tagged with Kind.NOTE should be tagged with the org.eclipse.core.resources.IMarker.SEVERITY_INFO severity. This should be fixed as part of the work in the BETA_JAVA7 branch as a new API is required in an API type: org.eclipse.jdt.core.compiler.IProblem.
This will involve updating the class org.eclipse.jdt.internal.ui.text.spelling.CoreSpellingProblem.
Created attachment 193061 [details] First draft This is exposing: isNote() for IProblem. Should we also add isOther() ? The best would have been to expose the severity directly, but there are things we cannot change.
(In reply to comment #2) The patch would cause an API change in CategorizedProblem, see bug 343176. You have to implement isNote() in CategorizedProblem. Then we don't need to change CoreSpellingProblem. See also bug 47340, which requested INFO severity a long time ago. I think we should consider this for 3.8 (nothing new in Java 7). We should stay with the severities that are known in Eclipse (IMarker#SEVERITY_INFO, IStatus#INFO, RefactoringStatus#INFO), so I would call the new method isInfo().
(In reply to comment #3) > (In reply to comment #2) > The patch would cause an API change in CategorizedProblem, see bug 343176. You > have to implement isNote() in CategorizedProblem. Then we don't need to change > CoreSpellingProblem. Will do. > See also bug 47340, which requested INFO severity a long time ago. I reopened it. > I think we should consider this for 3.8 (nothing new in Java 7). We should stay > with the severities that are known in Eclipse (IMarker#SEVERITY_INFO, > IStatus#INFO, RefactoringStatus#INFO), so I would call the new method isInfo(). Sure, we can wait for 3.8. The point of this bug is to improve our output from the Messager APIs. Right now it is pretty ugly :-).
*** Bug 47340 has been marked as a duplicate of this bug. ***
Will this addition also propagate into CompilerOptions, IrritantSet, etc.? Will "info" or "note" be available as a value for the problem ids in JavaCore? Will it be supported by the compiler preference page?
(In reply to comment #6) > Will this addition also propagate into CompilerOptions, IrritantSet, etc.? > > Will "info" or "note" be available as a value for the problem ids in JavaCore? > > Will it be supported by the compiler preference page? That was exactly the point of bug 47340, so the answer is yes, yes, and yes, if we can do it without too much collateral damage in clients of the existing APIs.
Changing onwership
FYI: M6 is API deadline.
(In reply to comment #9) > FYI: M6 is API deadline. Missed this :(. Looking at it right now.
I am inclined to move this out of 3.8. Please let me know if any of you think otherwise. Ofcourse, the primary reason is me. I didn't pay attention to this until now and I am afraid it is late now. Actually exposing the API is not hard, especially with the first patch draft in here. However, I think to really make it useful, points mentioned in comment 6 need to be implemented. These require significant changes in the JDT/Core and JDT/UI which we may not want to do at this point of time. Hence, I want to move.
(In reply to comment #11) > I am inclined to move this out of 3.8. Please let me know if any of you think > otherwise. I'm fine with that.
