[slf4j-dev] level based on enums

[Ceki Gülcü]

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/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.