commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Rosenvold <>
Subject Re: svn commit: r1686472 - in /commons/proper/io/trunk/src: main/java/org/apache/commons/io/ main/java/org/apache/commons/io/ test/java/org/apache/commons/io/
Date Sun, 21 Jun 2015 12:12:58 GMT
2015-06-21 13:43 GMT+02:00 sebb <>:
> 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:
> For additional commands, e-mail:

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