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 21:00:56 GMT
> [...]
>>>> 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.

(Broken) thread-safety is going to be removed:
   https://issues.apache.org/jira/browse/MATH-757

>>>
>>> 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.

What I meant is that it's a pity that valid uses must be suppressed
in order to detect invalid code (which will then be suppressed, of
course)...

Gilles


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


Mime
View raw message