Community
Participate
Working Groups
This is a spin-off from bug 244631. JDT Core is generating a large number of warnings in certain cases. For example, when importing 1.4 level source code into a new project that has a default target setting of 1.5, you will get a spew of type safety and raw types warnings. In the past, there have been efforts to minimze the number of generated errors/warnings - should something done about this case as well? Copied from bug 244631 comment 45: > Note that there are many potential optimizations you could do on the client > side: > - Don't generate as many markers - I doubt that end users will be able to do > anything about them if they see markers in the 100,000s. Some ideas: > . When you encounter problems that may have been caused by earlier problems, > don't report them if they are indeed a follow-up problem. > . After reporting a certain number of problems per file/folder/project (the > exact number and scope depends on your domain), stop reporting more and instead > generate one more marker saying that you stopped looking for more problems. Very interesting discovery I just made as I was trying to determine which one of our validators was producing so many markers in one of our large workspaces we test with. 1) First I grouped the markers by type and found that 186,374 out of 228,187 (82%) were Java Problems! 2) Then I grouped the markers by Java Problem type and found 131,702 out of 186,374 (71%) were due to type safety and raw types warnings (which . These type safety and raw type warnings contribute to 58% of the markers here on the entire workspace. 3) I compared it with a run of our previous product version (based on Eclipse 3.2). There were 77,447 Java problems. This means our product based on Eclipse 3.4 saw an increase of 108,927 Java problem type markers on the same workspace. The Type safety and Raw type category increased from 30,545 to 131,702 markers. Is there any optimization JDT can do here with those warnings? Perhaps taking some of the tips you've outlined here Boris?
Interesting data. Indeed Java 1.4 code is doomed in 1.5 compliance level. In the past, we restrained the amount of problems generated by introducing some maximum numbers of problems per unit; and blocked builds in presence of broken buildpath. We avoid secondary errors in quite some cases already, and we already have a limit of 100 problems per file (configurable option), but if every single file is producing 100 of them, in this scenario, we end up with tons of warnings still. Couple thoughts: - the unchecked warnings are enabled per default - the raw type warnings are enabled per default Ernest - can you quantify if you are getting overhelmed by raw type warnings or not ? Maybe we could default for these to be ignored ? (leave them up to users) Or at least not report the problem more than once per method ?
Clearly this is a case where some warnings should be removed. Ernest, could you please provide the requested information?
(In reply to comment #2) > Clearly this is a case where some warnings should be removed. Ernest, could you > please provide the requested information? Sorry I missed this question earlier. Boris copied my comments from bug 244631, so the analysis is from me initially from the workspace I had a hold of. "2) Then I grouped the markers by Java Problem type and found 131,702 out of 186,374 (71%) were due to type safety and raw types warnings. These type safety and raw type warnings contribute to 58% of the markers here on the entire workspace." Is this what you guys are looking for?
In this case these warnings should be disabled in such settings. I am not aware of cases where we report warnings that should not be reported. We will always have a performance hit when you reach hundreds of thousands of warnings. I would close as WONTFIX. Reopen if you believe this is worth investigating time to handle that case better.
Verified for 3.6M5
Verified.
