[slf4j-dev] level based on enums

[Ralph Goers]

Since adding Messages doesn't break the API I'd still like it added in 1.6.

Ralph

On May 3, 2010, at 3:38 AM, Ceki Gülcü wrote:

> 
> 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.
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-dev