On Aug 7, 2013, at 2:41 AM, Mark Thomas wrote: > For trunk we have been running a policy of zero warnings in the code. > This has helped to highlight issues as code is edited as any warnings > are immediately clear. Obviously, this depends on what warnings are enabled. > > Currently, we use Eclipse's "Ignore unavoidable generic type problems." > Recently a couple of issues has been highlighted with this: > 1. Other IDEs might not have this setting. > 2. javac does not have this setting > 3. Some of the problems Eclipse excludes are avoidable (well, sort of > avoidable as avoiding them requires using JRE methods that themselves > have @SuppressWarnings annotations). > > In favour of the current situation is that it reduces clutter in the > code base slightly. > > While I am all for reducing clutter in the code base, there do appear to > be good reasons for disabling the "Ignore unavoidable generic type > problems." and using @SuppressWarnings instead. > > Personally, I am happy with the current settings but not unhappy to > change. I guess that makes me +0 on changing. What does everyone else think?
(Non-binding) As stated earlier, I am fundamentally opposed to the concept of using an IDE-specific setting to decide how a project writes code. This practically forces all developers to use that IDE exclusively for that project. If I'm writing Tomcat code in IntelliJ IDE and I create a warning, I have no idea whether I should correct the warning or not, because I have no idea what Eclipse has to say about it. I do, however, know that the warning will show up when I compile, and I think that's what matters most. We should make efforts to eliminate all warnings that show up when we compile, whether Eclipse calls them "unavoidable" or not. My $0.02. Nick --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
