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