On 6/1/14, 6:01 PM, Bernd Eckenfels wrote: > Am Sun, 1 Jun 2014 23:43:10 +0100 > schrieb sebb <seb...@gmail.com>: > >> On 1 June 2014 20:19, Romain Manni-Bucau <rmannibu...@gmail.com> >> 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. > 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).
Right, except that the logger is itself mutable and it looks like clients hold onto references to it. What I don't get is why it is so much faster to add the overhead of the helper just to avoid a call to logger.isDebugEnabled(). I would expect that to return just as fast as the LOG_HELPER inspecting its (even cached) boolean. What am I missing? Phil > > 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. > > Gruss > Bernd > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
