[slf4j-dev] updated 2.0 proposal

[John Vasileff]

On Sep 17, 2011, at 3:05 PM, Joern Huxhorn wrote:

> I just checked out your code at https://github.com/jvasileff/slf4j/blob/topic-jdk5-varargs/slf4j-api/src/main/java/org/slf4j/Logger.java (only that file so far) and I can tell you that this interface won't be compatible with jdk1.4.
> 
> Yes, I know, this is the jdk5 proposal. But I agree with Ceki that there should be an interface staying jdk1.4-compatible. This is not only relevant for ordinary Java but also for stuff like JavaME.
> 

My understanding is that Ceki would prefer not having a new package, and that forcing 2.0 users to deploy on Java 5+ is ok.  My opinion is that having two interfaces would be confusing, especially since logging is something people don't want to put a lot of thought into.

Should we really cater to apps deployed on Java 1.4, especially when those apps are unlikely to even attempt to upgrade to SLF4J v2?  Any other dependencies that bring in SLF4J v2 as a transitive dependency are also likely to require Java 5.  I'm sure it is no joy enhancing 1.4 apps, but a new library that requires Java 5 is nothing new to those that do.

http://www.qos.ch/pipermail/slf4j-dev/2010-March/002857.html
http://www.qos.ch/pipermail/slf4j-dev/2010-March/002866.html

> Also, the Message interface is only used in the log-method and not in case of the explicit methods like debug, info, etc.

Easy enough to add info(Message), etc. if desired.  The code works pretty well, but is certainly not final.

> 
> Third, Loggers in your proposal are mutable. Changing the formatter of a logger is a very bad idea™. I explained this earlier.

Actually, the way it is done the logger is not mutable.  But, as I noted, I am not proposing 2.0 include withFormatter() - it is more of an experiment to see how something like that may be done in case it leads towards a more flexible/superior design.

> 
> Joern.
> 
> On 17.09.2011, at 20:39, John Vasileff wrote:
> 
>> Joern, I can't help but think having Entry objects that include Level & Marker is a major sticking point with this.  I put more thought into Entry objects, and have reached a couple conclusions.  First, with the other proposed changes, this feature could be added later without breaking things using a LevelProvidingMessage and corresponding Logger method.  Second, one of the major advantages is the ability for an Entry to determine its own Level and Marker.  But this comes at a performance cost as the Entry would have to be constructed prior to checking isEnabled.
>> 
>> So, with that, I reworked my branch to have Message objects that more closely resemble those in your branch.  (The current Message objects are rudimentary and would need to be updated with the work from your branch.)
>> 
>> To recap, this proposal includes:
>> 
>> - Much simplified adapter implementation requirements while improving separation of concerns and freedom for future slf4j-api innovation.
>> - Binary and source compatibility with 1.6.x adapters and application code.
>> - Support for new Logger methods including Message objects when using legacy adapters.
>> - No change in the package names for org.slf4j.Logger, LoggerFactory, etc.
>> 
>> - Resolves the following:
>> http://bugzilla.slf4j.org/show_bug.cgi?id=245
>> http://bugzilla.slf4j.org/show_bug.cgi?id=244
>> http://bugzilla.slf4j.org/show_bug.cgi?id=243
>> http://bugzilla.slf4j.org/show_bug.cgi?id=242
>> http://bugzilla.slf4j.org/show_bug.cgi?id=241
>> http://bugzilla.slf4j.org/show_bug.cgi?id=148
>> http://bugzilla.slf4j.org/show_bug.cgi?id=31
>> 
>> - Resolves confusion behind the following:
>> http://bugzilla.slf4j.org/show_bug.cgi?id=213
>> http://bugzilla.slf4j.org/show_bug.cgi?id=240
>> 
>> - Allows easy addition of (if desired):
>> http://bugzilla.slf4j.org/show_bug.cgi?id=133
>> 
>> 
>> John
>> _______________________________________________
>> slf4j-dev mailing list
>> slf4j-dev at qos.ch
>> http://qos.ch/mailman/listinfo/slf4j-dev
> 
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-dev