commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [MATH] Dealing with boxing/unboxing
Date Thu, 18 Jul 2013 20:06:52 GMT
On 18 July 2013 20:42, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 7/18/13 12:29 PM, sebb wrote:
>> On 18 July 2013 19:54, Gilles <gilles@harfang.homelinux.org> wrote:
>>> 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?
>> Yes, of course, but the feature is not without its drawbacks as I
>> already mentioned.
>> - conversion overhead
>> - unexpected NPE when unboxing
>> - ambiguous remove() behaviour
>>
>> For example:
>> x=1
>> list.remove(x);
>>
>> Does that remove element number 1 or teh element with key value 1?
>>
>> The answer is that it depends on the type of x.
>>
>>> Which checking software is producing the warnings?
>> Eclipse compiler is what I use.
>>
>>> Why didn't it bother us before?
>> Depends on your compiler/IDE settings.
>>
>>> Are there any cases beyond those of constructing exceptions?
>> Yes, there are quite a lot of classes that use Lists.
>> Could potentially save a lot of conversions if there were some basic
>> primitive array lists (probably only need a growable list).
>
> We have ResizeableDoubleArray for doubles if that is helpful.

Thanks,

Looks like it might perhaps be useful, although most of the cases I
have seen don't need thread-safety.
Maybe there is scope for simpler versions which are not thread safe.
I may try and collect some info on how the existing lists are used.

>>
>> There is at least one instance where a private method [1] returns null
>> for error and the main code immediately throws an Exception.
>> That could probably be recoded to avoid the conversions. The class
>> also unboxes pivotCol without checking for null.
>> It might be possible to cause an NPE by suitable choice of input.
>>
>> [1] SimplexSolver#getPivotRow
>>
>>> If not, isn't there a way to disable this (spurious, IMO) check?
>> It's only spurious if you ignore the downsides.
>>
>>> Introducing the overloads above just to suppress warnings about
>>> valid uses of a Java feature does not seem right.
>> Actually, it's precisely the valid uses that I want to suppress, so
>> that the potentially harmful uses are highlighted.
>
> I am +1 for letting Sebb do what he can to reduce overhead and cut
> the warnings down to things we should pay attention to.  FWIW, this
> "Java feature" has always smelled a little to me :)

Indeed; I think it causes more trouble than it is worth.

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

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


Mime
View raw message