[slf4j-dev] updated 2.0 proposal

[Joern Huxhorn]

On 17.09.2011, at 21:35, John Vasileff wrote:

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

Extending an interface can not be done in a binary-compatible way (at least not until jdk8 with extension methods, see http://www.javarants.com/2011/01/22/using-closures-method-handles-and-extension-methods-in-java-8-jsr-335/ ) simply because all outside implementations of the interface will go boom because they don't implement the new methods.

That's one of the reasons why I suggested moving over to a fresh interface. This enables us to remove superfluous methods like the ones with one or two arguments while also extending it at other places, like Message support. This is also the way people are doing it in other projects, for example JUnit and commons-lang.

It's not only people that are too lazy to update their Java installation. Some are simply forced to use old versions (I remember someone needed to work on AS/400). Those could still use the old API without being cut off from fixes.

Having two interfaces isn't more confusing than the old and new junit packages. People that don't care can just stay on the old interface without any work on their side while people that do care can switch to the new interface if they like.

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

I know. Been there, done that. ;)

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

If they are not mutable than you have multiple instances of the same Logger that was originally meant to be a singleton.

Joern.

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