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

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


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

View raw message