Re: [slf4j-dev] Static binding...
Hi Joern, Well, it's more of a java question than slf4j. The difference is between direct method call and a method call via reflection. The latter is known to be a bit slower and is also harder to read. There might also be subtle class loader differences. Joern Huxhorn wrote:
I was wondering if there is a real substantial difference between
a) ILoggerFactory factory=org.slf4j.impl.StaticLoggerBinder.getLoggerFactory();
and
b) ILoggerFactory factory=(ILoggerFactory) Class.forName("org.slf4j.impl.StaticLoggerBinder").getMethod("getLoggerFactory").invoke(null);
I mean, are the classes resolved any different?
Beside a compile-time error in case of a) if the class is missing, of course.
Regards, Joern.
-- Ceki
Hi Ceki, I asked it here because the static binding of the actual logging implementation is a seemingly important SLF4J feature. My guess is that this was important when SLF4J was still using StaticLoggerBinder.SINGLETON and now it's only there for historical reasons. I'm interested in those subtle differences. I'm not aware of any. Also, I'm asking the question because I've gone completely insane. I started an slf4j-redesign at http://github.com/huxi/slf4j/tree/slf4j-redesign/slf4j-n-api/ You were right, btw. My initial idea wouldn't have worked in case of Logger deserialization. But I avoided that problem, now. My plan is the following (as documented in NewLoggerWrappingOld): It is used if a binding does not implements org.slf4j.n natively, i.e. the class org.slf4j.n.impl.StaticLoggerBinder does not exist. In that case, a fallback ILoggerFactory implementation is used that returns an instance of this class containing the logger returned by org.slf4j.LoggerFactory.getLogger(..). I've not finished the implmenetation (LoggerFactory isn't done yet) but the n.Logger interface looks as planned and the implementation of AbstractLogger NewLoggerWrappingOld and OldLoggerWrappingNew are more or less done. The LoggerFactory implementation, as planned, would require me to get the singleton using ILoggerFactory factory=(ILoggerFactory) Class .forName ("org .slf4j .impl.StaticLoggerBinder").getMethod("getLoggerFactory").invoke(null); That's why I'm asking... Regards, Joern. On 26.11.2009, at 17:55, Ceki Gülcü wrote:
Hi Joern,
Well, it's more of a java question than slf4j. The difference is between direct method call and a method call via reflection. The latter is known to be a bit slower and is also harder to read. There might also be subtle class loader differences.
Joern Huxhorn wrote:
I was wondering if there is a real substantial difference between a) ILoggerFactory factory=org.slf4j.impl.StaticLoggerBinder.getLoggerFactory(); and b) ILoggerFactory factory=(ILoggerFactory) Class .forName ("org .slf4j .impl .StaticLoggerBinder").getMethod("getLoggerFactory").invoke(null); I mean, are the classes resolved any different? Beside a compile-time error in case of a) if the class is missing, of course. Regards, Joern.
-- Ceki _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
Hi Joern, The idea behind static binding was to employ the least sophisticated java idiom available, so that anyone could read and understand the code within minutes. This had the additional benefit of making it easier to debug problems in the field as well. StaticLoggerBinder.SINGLETON has been replaced with StaticLoggerBinder.getSingleton() a few years ago. It's a minor change from a design point of view. The design of SLF4J, as far the binding stategy is concerned, has not really changed since the beginning. We've added defensive code but that's about it. Getting the logger through reflection would actually cleaner from a packaging point of view. However, we wouldn't be as a dumb as we possibly can. :-) Joern Huxhorn wrote:
Hi Ceki,
I asked it here because the static binding of the actual logging implementation is a seemingly important SLF4J feature. My guess is that this was important when SLF4J was still using StaticLoggerBinder.SINGLETON and now it's only there for historical reasons.
I'm interested in those subtle differences. I'm not aware of any.
Also, I'm asking the question because I've gone completely insane.
I started an slf4j-redesign at http://github.com/huxi/slf4j/tree/slf4j-redesign/slf4j-n-api/
You were right, btw. My initial idea wouldn't have worked in case of Logger deserialization. But I avoided that problem, now.
My plan is the following (as documented in NewLoggerWrappingOld): It is used if a binding does not implements org.slf4j.n natively, i.e. the class org.slf4j.n.impl.StaticLoggerBinder does not exist. In that case, a fallback ILoggerFactory implementation is used that returns an instance of this class containing the logger returned by org.slf4j.LoggerFactory.getLogger(..).
I've not finished the implmenetation (LoggerFactory isn't done yet) but the n.Logger interface looks as planned and the implementation of AbstractLogger NewLoggerWrappingOld and OldLoggerWrappingNew are more or less done.
The LoggerFactory implementation, as planned, would require me to get the singleton using ILoggerFactory factory=(ILoggerFactory) Class.forName("org.slf4j.impl.StaticLoggerBinder").getMethod("getLoggerFactory").invoke(null);
That's why I'm asking...
Regards, Joern.
On 26.11.2009, at 17:55, Ceki Gülcü wrote:
Hi Joern,
Well, it's more of a java question than slf4j. The difference is between direct method call and a method call via reflection. The latter is known to be a bit slower and is also harder to read. There might also be subtle class loader differences.
Joern Huxhorn wrote:
I was wondering if there is a real substantial difference between a) ILoggerFactory factory=org.slf4j.impl.StaticLoggerBinder.getLoggerFactory(); and b) ILoggerFactory factory=(ILoggerFactory) Class.forName("org.slf4j.impl.StaticLoggerBinder").getMethod("getLoggerFactory").invoke(null); I mean, are the classes resolved any different? Beside a compile-time error in case of a) if the class is missing, of course. Regards, Joern.
-- Ceki _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
participants (3)
-
Ceki Gulcu -
Ceki Gülcü
-
Joern Huxhorn