[slf4j-dev] level based on enums

[Joern Huxhorn]

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/org/slf4j/n/Level.java
http://github.com/huxi/slf4j/blob/slf4j-redesign/slf4j-n-api/src/main/java/org/slf4j/n/Threshold.java

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.