First about immutabilit thread safety etc: we can use final if it ends the topic, it was not cause first version was a field and not a constant and serializable but now it can be final.
Then about isDebugEnabled: overhead is quite important compared to a simple boolean test. Most of the time it is not important but for a caching solution (in particular in memory mode) it is impacting since it is done very often. To be convinced of it just debug log4j (1.2) impl for instance. Really depends the config too but basically you'll end up checking repository level + potentially browse all logger categories. If config is well done no by overhead by if not that's really too much. If you take JUL that's worse. isDebugEnabled is fast but then log invocation has more check (record, filter, handlers at least). Actually I think we can do further proposing a JCS property "verbose" and get rid of logger level for these cases. We can add a shared MBean to on/off it then. wdyt? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-06-02 16:27 GMT+02:00 Phil Steitz <phil.ste...@gmail.com>: > 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 > >
