On 7/18/13 12:29 PM, sebb wrote: > On 18 July 2013 19:54, Gilles <[email protected]> wrote: >> Hi. >> >> >> On Thu, 18 Jul 2013 19:02:34 +0100, sebb wrote: >>> On 18 July 2013 17:56, Mark Thomas <[email protected]> wrote: >>>> sebb <[email protected]> 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).
We have ResizeableDoubleArray for doubles if that is helpful. > > 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 :) Phil > >> Regards, >> Gilles >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
