Use (or not) of @SuppressWarnings

[Mark Thomas <ma...@apache.org>]

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?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Use (or not) of @SuppressWarnings

[Mark Thomas <ma...@apache.org>]

On 07/08/2013 09:41, 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?

The consensus seems to be to change them.

I'll get that done shortly for trunk and 7.0.x.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Use (or not) of @SuppressWarnings

[Brian Burch <br...@PingToo.com>]

On 07/08/13 19:49, Konstantin Kolinko wrote:
> 2013/8/7 Brian Burch <br...@pingtoo.com>:
>>
>> I use netbeans exclusively. I get warnings about import order from almost
>> every tc source file. Periodically I scratch around looking for the rules
>> template so I can change them to conform with the ant checkstyle rules,
>> which are happy with the current import order. So far, no luck, so I live
>> with netbeans nagging and resist the temptation to let it re-order the
>> imports for me.
>>
> Imports order is not IDE-specific. It is enforced via checkstyle.

Yes, I said that with different words in my closing paragraph. I 
followed the order of Jeremy's response, but perhaps I could have been 
clearer if I had said that first. checkstyle defines the style that 
everyone's code must follow - regardless of what our IDEs might think.

> The order of import groups should be configurable in your IDE.

I agree with you!

> I have never used NetBeans, but there is a screenshot of configuration dialog:
> http://plugins.netbeans.org/data/images/1307540397_organizeImports.png

That was extremely kind of you, Konstantin. Thank you for taking the 
time to try helping me. I had not previously found your screen shot - 
probably because I have google set to only give me English and French.

It was useful because my primitive German was good enough to translate 
the tab title and search for the plugin. Unfortunately, that quickly 
took me back over well-trodden ground. The Organize Imports plugin does 
not exist for netbeans 7.1.x. The quoted reason is it has been 
"incorporated into NetBeans".

My netbeans options for the internal editor does not even have the 
Organize Imports tab shown in your screen shot! I can find customisation 
for hints about imports that break the current rules, but I can't find 
the actual rules!

Please don't worry any more. I will live with the warnings until I 
eventually work out how to change the rules. Rest assured that as soon 
as I succeed, I will add the recipe to README.txt and the wiki.

Brian

> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Use (or not) of @SuppressWarnings

[Konstantin Kolinko <kn...@gmail.com>]

2013/8/7 Brian Burch <br...@pingtoo.com>:
>
> I use netbeans exclusively. I get warnings about import order from almost
> every tc source file. Periodically I scratch around looking for the rules
> template so I can change them to conform with the ant checkstyle rules,
> which are happy with the current import order. So far, no luck, so I live
> with netbeans nagging and resist the temptation to let it re-order the
> imports for me.
>


Imports order is not IDE-specific. It is enforced via checkstyle.

The order of import groups should be configurable in your IDE.

I have never used NetBeans, but there is a screenshot of configuration dialog:
http://plugins.netbeans.org/data/images/1307540397_organizeImports.png

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Use (or not) of @SuppressWarnings

[Brian Burch <br...@PingToo.com>]

On 07/08/13 14:14, Nick Williams wrote:
>
> 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.

OK, I'll add my non-binding penny.

I use netbeans exclusively. I get warnings about import order from 
almost every tc source file. Periodically I scratch around looking for 
the rules template so I can change them to conform with the ant 
checkstyle rules, which are happy with the current import order. So far, 
no luck, so I live with netbeans nagging and resist the temptation to 
let it re-order the imports for me.

I think ant should compile without warnings. I think we should all put 
up with whatever our ide's bleat about... or figure out how to coerce 
them to follow the external/common build code style rules.

> Nick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Use (or not) of @SuppressWarnings

[Nick Williams <ni...@nicholaswilliams.net>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Use (or not) of @SuppressWarnings

[Christopher Schultz <ch...@christopherschultz.net>]

Jeremy,

On 8/7/13 11:38 AM, Jeremy Boynes wrote:
> On Aug 7, 2013, at 12:41 AM, Mark Thomas <ma...@apache.org> 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?
> 
> I would prefer to use @SuppressWarnings for this rather than an IDE setting as that keeps the information in the code.
> A stronger +1 for changing.

+1

@SuppressWarnings is likely to enjoy wider support across IDEs and has
the added benefit of actually having an effect when building with ant.

-chris

Re: Use (or not) of @SuppressWarnings

[Jeremy Boynes <jb...@apache.org>]

On Aug 7, 2013, at 12:41 AM, Mark Thomas <ma...@apache.org> 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?

I would prefer to use @SuppressWarnings for this rather than an IDE setting as that keeps the information in the code.
A stronger +1 for changing.
--
Jeremy