commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [MATH] Dealing with boxing/unboxing
Date Thu, 18 Jul 2013 18:54:20 GMT
Hi.

On Thu, 18 Jul 2013 19:02:34 +0100, sebb wrote:
> On 18 July 2013 17:56, Mark Thomas <markt@apache.org> wrote:
>> sebb <sebbaz@gmail.com> wrote:
>>
>>>The MATH code base currently generates hundreds of boxing warnings.
>>>Many, if not most, are perfectly OK.
>>>For example, conversion of int and long to Number when throwing
>>>various Exceptions.
>>>
>>>However, buried amongst the valid uses there may well be some code
>>>that is buggy - e.g. it uses Long when it could use the primitive 
>>> and
>>>avoid the conversion overhead.
>>>Or there is an unboxing conversion that fails to check if the field 
>>> is
>>>null.
>>>
>>>At present, there are just too many warnings for them to be any use.
>>>
>>>It occurs to me that it would be easy to add overloaded methods for
>>>the Exceptions, for example
>>>
>>>NumberIsTooLargeException(Number, Number, boolean)
>>>
>>>could have the following overloads:
>>>
>>>NumberIsTooLargeException(int, int, boolean)
>>>NumberIsTooLargeException(long, long, boolean)
>>>NumberIsTooLargeException(float, float, boolean)
>>>NumberIsTooLargeException(double, double, boolean)
>>>
>>>The int and float versions could probably be omitted without losing
>>>essential information.
>>>
>>>Thoughts?
>>
>> From the peanut gallery that seems to be a perfectly reasonable 
>> approach to reduce the warnings. If you add those methods (I'm 
>> guessing you are in a position to do that pretty quickly) does it 
>> reduce the number of warnings to a manageable level?
>
> I'm hoping so, but did not want to start on something that was going
> to be rejected.
>
> There are currently 1705 boxing warnings (and about 300 unboxing)
> This includes the test cases.
>
> Adding public NumberIsTooLargeException([Localizable l.]long wrong,
> long max, boolean boundIsAllowed)  and the double equivalents
> reduces the number to 1577, i.e. 128 fewer. Still a way to go, but
> there are quite a lot of these Exceptions.

Maybe I'm missing something but: Isn't auto-boxing supposed to
be a feature?

Which checking software is producing the warnings? Why didn't it
bother us before?
Are there any cases beyond those of constructing exceptions?
If not, isn't there a way to disable this (spurious, IMO) check?
Introducing the overloads above just to suppress warnings about
valid uses of a Java feature does not seem right.


Regards,
Gilles


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


Mime
View raw message