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 12:12:58 GMT
2015-06-21 13:43 GMT+02:00 sebb <sebbaz@gmail.com>:
>
> Final variables are guaranteed to be safely published across threads.
> Is that true for non-final variables if they are established in a static
> block?
>

Yes. All static blocks are guranteed to be visible (all class
initialization is basically a synchronized operation for that class) and as
long as they're effectively immutable it does not really matter. Style wise
I would personally also prefer to make them final, but that would actually
increase the overall footprint of the code somewhat (believe me, I tried
when I initially wrote this code...)

So I think this code is nicer, but it's really only a very subtle
preference and I'm definitely not married to this way of doing it :)

>
> > 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.
>
> So I always set Eclipse to warn where implicit (un)boxing is occurring.
> Yes, it requires a bit more work by the developer, but it ensures that
> the (un)boxing really is intentional.
>
> > Is there some other mechanism you're thinking of ?
>
> No.
>
> >
> > Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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