commons-dev mailing list archives

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

On Thu, 18 Jul 2013 19:02:34 +0100, sebb wrote:
> On 18 July 2013 17:56, Mark Thomas <> wrote:
>> sebb <> 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
>>>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.
>> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message