On 18 July 2013 20:42, Phil Steitz <phil.ste...@gmail.com> wrote: > On 7/18/13 12:29 PM, sebb wrote: >> 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). > > 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. >> >> 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. > Phil >> >>> 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 >> >> > > > --------------------------------------------------------------------- > 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
