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
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
