On 07/18/2013 09:29 PM, sebb wrote:
> On 18 July 2013 19:54, Gilles <gil...@harfang.homelinux.org> wrote:
>> Hi.
>>
>>
>> On Thu, 18 Jul 2013 19:02:34 +0100, sebb wrote:
>>>
>>> On 18 July 2013 17:56, Mark Thomas <ma...@apache.org> wrote:
>>>>
>>>> sebb <seb...@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
There are even more downsides, as it allows you to write compilable code
that is simply wrong:
Set<Long> s = new HashSet<Long>();
s.add(1l);
System.out.println(s.contains(1));
This will never work, unless you explicitly cast it to a long or create
a Long object yourself.
Imho, autoboxing should be disabled by default. The benefit is
negligible but the consequences of wrong usage are really hard to track
down.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
