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?
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.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
