commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Rosenvold <kristian.rosenv...@gmail.com>
Subject Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/FileUtils.java main/java/org/apache/commons/io/Java7Support.java test/java/org/apache/commons/io/FileUtilsCleanSymlinksTestCase.java
Date Sun, 21 Jun 2015 13:16:02 GMT
2015-06-21 14:53 GMT+02:00 sebb <sebbaz@gmail.com>:

> On 21 June 2015 at 13:24, Kristian Rosenvold
> <kristian.rosenvold@gmail.com> wrote:
> > 2015-06-21 13:43 GMT+02:00 sebb <sebbaz@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. 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.

Kristian

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message