commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: svn commit: r1598071 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/disk/ engine/control/ engine/memory/ utils/logger/ utils/struct/
Date Mon, 02 Jun 2014 17:07:16 GMT
On 2 June 2014 02:01, Bernd Eckenfels <> wrote:
> Am Sun, 1 Jun 2014 23:43:10 +0100
> schrieb sebb <>:
>> On 1 June 2014 20:19, Romain Manni-Bucau <>
>> wrote:
>> > well it is for sure thread safe. Not sure I get why final and synch
>> > would be mandatory in this particular case (field will maybe be
>> > cached by thread but that's not an issue since the value will be
>> > unique).
>> non-final fields are not guaranteed to be published across threads in
>> the absence of sync.
> The two fields wont change, so there is no need for publishing changes.

But the initial value still has to be published correctly.

> So they dont need to be volatile. They could be made however final to
> make it clearer that they will not change (but IMHO this does not make
> them more or less thread safe).

Final fields are guaranteed to be published safely.

> I feel indifferent about beeing able to turn off trace/debug by
> overwriting the underlying logger. If we are really so logger
> agnostic it is probably a good idea. At least when commons-logging is
> not able to abstract this shortcoming away.

I was not proposing changing the underlying logger.
But it can sometimes be useful to change the log level during a test run.
The caching prevents this.

> Gruss
> Bernd
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message