Community
Participate
Working Groups
Compilation errors are sorted according to line number. But, this is not necessarily the order in which the Java compiler generated the errors. For example: class Blah { void bar() { foo(); } Vectro foo() { return null; } } In this case, the type Vectro is not found, which creates a secondary compile error in the method bar(). Since the secondary error has a lower line number, it will appear before the more important compile error. To solve this, perhaps another attribute similar to line number could be generated. Maybe a "rank" or something. Then, errors could be sorted by the order in which they are generated, not the order in which they appear.
Better sorting problems is something we want to consider. In particular, certain kind of problems generate some ripple effects, and cause lots of distracting secondary problems. Type errors are usually more significant than others. And fixing these first is likeky addressing lots of issues at once. This is the kind of criteria we want to add, and this should pretty much give you the behavior you expected.
For quite a long time, we were willing to investigating improving our sorting order for Java problems. Since we had to fit inside the task list, there was no such criteria we could tag our problems with so as to achieve this (only sorting per fixed columns). Could we improve this for 3.0 ? I am thinking of having more granularity in severities which would allow smarter heuristics. I would imagine having 4 or 5 severities per category (Warning, Error).
From Nick: There was also the idea of tagging problems as being primary or secondary, which would allow further filtering.
Primary/secondary is also something worth considering. We investigated this quite a while ago, and could resurrect some code to take advantage of this. Still certain errors are far more important than others, and I think we would need a combination of both enhancements. Moving to platform/ui for adding support, then we can provide better problem sorting strategies.
I don't think the solution should be limited to an attribute that the user wants to look at. For example, some kind of severity attribute that is numbered 1-5. Maybe the new attribute could be any String, and it would be used as the secondary sorting criterium after Error, Warning, etc. As a used, I don't think I need to see this column, only its effects.
As mentionned in related bug 47340, we could use PRIORITY as a way to better prioritize problems. This goes along the line of comment #5.
We have added sorting by proirity and categorization
