On 21 June 2015 at 14:16, Kristian Rosenvold <kristian.rosenv...@gmail.com> wrote: > 2015-06-21 14:53 GMT+02:00 sebb <seb...@gmail.com>: > >> On 21 June 2015 at 13:24, Kristian Rosenvold >> <kristian.rosenv...@gmail.com> wrote: >> > 2015-06-21 13:43 GMT+02:00 sebb <seb...@gmail.com>: >> > >> >> >> >> > I'm not sure I understand; the equivalent of >> >> > >> >> > Boolean result = (Boolean) isSymbolicLink.invoke(null, path); >> >> > return result.booleanValue(); >> >> > >> >> > Gives a style warning (uneccssary unboxing) in IntelliJ. >> >> >> >> That warning is wrong. >> >> >> >> Unboxing is clearly necessary here; it's just a question of whether it >> >> is implicit or explicit. >> >> >> >> I have seen several cases where implicit boxing was associated with a >> code >> >> bug. >> >> For example, a local variable was defined as Boolean but always used as >> >> boolean. >> >> >> > >> > This makes me curious; the only bug I know of in this context is the >> clasic >> > NPE you can get in the automatic unboxing. Is there some other scenario >> > you're thinking of ? (Uneccessary object allocation is obvious and >> > something we try to avoid but hardly a bug. In this case I also think the >> > object is unavoidable...) >> >> IMO it is a bug to write code that uses unnecessary (un)boxing. >> Not a very serious bug in general, though it might well have a >> performance impact if done repeatedly. >> > > But there is no unnecessary unboxing here, hence no bug.
Exactly, so the IntelliJ warning is wrong. > I work on way too > many projects with way too many code styles to care about arguing these > matters. If old-style explicit unboxing is how you want it around here, > that's what I'll write. > > > >> There was another scenario which I came across a while ago. >> Unfortunately I did not keep a note of it, but IIRC it was not just a >> performance/NPE issue >> > > That would be interesting to hear about if you remember. Selection of > different overloads is the only one I can think of. It could have been that. I'm pretty sure it was a Commons component that had the issue. > Kristian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
