Hello all, In light of your comments below and assuming that an overhaul of the SLF4J API cannot be done in a short amount of time, I think that my plan for 1.6 and 2.0 compatibility is looking less realistic. SLF4J version 2.0 which is planned to require Java 5 will provide us a good opportunity to modify SLF4J API and start to use Java 5 functionality in both SLF4J API and code. So instead of cramming changes into 1.6 that we might later regret, I think we should release 1.6 as soon as possible so that users can take advantage of nop-defaulting right now and take our time working on SLF4J 2.0. More formally, - Release 1.6.0-alpha2 as 1.6.0 - Require Java 5 for SLF4J 2.0 - Allow for breaking-changes in 2.0 so that we can incorporate new functionality and API additions for v2.0 Does that sound OK? On 01/05/2010 11:18 AM, Joern Huxhorn wrote:
On 30.04.2010, at 19:16, Ceki Gülcü wrote:
Beside that, I'm very hesitant about adding Level at this point (read: I think it's a very bad idea), anyway, since the proper way of implementing it would be an enum but we need to stay 1.4-compatible for now, right? If we introduce it now then we won't be able to change it into an enum later on. That's why I would NOT add Level to SLF4J right now. I'd do this during the big 1.5 update sometime in the future.
Indeed.
Using enums for levels will require JDK 1.5 so we won't be able to use enums in SLF4J 1.6 which still targets JDK 1.4. Compared to typed level classes, e.g. java.util.logging.Level, ch.qos.logack.classic.Level and org.apache.log4j.Level, levels based on Java 5 enums offer little benefit. Yes, enums can be used as case labels, but how difficult is to write the following?
int levelInt = level.toInt(); switch(levelInt) { case Level.TRACE_INT: ...; case Level.DEBUG_INT: ...; case Level.INFO_INT: ...; etc. }
Do you see other benefits of a level based on enums over a typed level? If not, I think we can stick with typed levels even after SLF4J 1.6. If you wish to pursue this subtopic, I suggest creating a new thread named "level based on enums" or similar.
Did that ;)
It's already possible to implement this kind of functionality in current SLF4J so I don't think that adding logging-methods with a generic level are an important issue right now. We are not forced to add it ASAP since a "workaround" exists and it's not adding new functionality in the sense that one can do something that isn't already possible.
Yes, it's not perfect that one has to implement such code but it's possible anyway.
I'm not sure if you've seen the Level and Threshold enums in slf4j-n-api. They contain additional logic to check if a Level passes.
http://github.com/huxi/slf4j/blob/slf4j-redesign/slf4j-n-api/src/main/java/o... http://github.com/huxi/slf4j/blob/slf4j-redesign/slf4j-n-api/src/main/java/o...
There's no magic in it, it's just neat to be able to add additional functionality to those enums, assuming that a Logger would have a retrievable Threshold.
My main point is that Level is more or less a prime example of an enum use-case. A modern API would use an enum so we should, too, as soon as we require Java 1.5. It gives us the opportunity to add functionality, if necessary, and frees us from implementing immutability, cloning and deserialization ourselves.
Joern.