[slf4j-dev] [Bug 31] Varargs for Logger methods

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=31





--- Comment #60 from Mark A. Ziesemer <bugs at mark.ziesemer.com>  2009-11-15 03:05:50 ---
In response to comment #58 and comment #59:

How is "Runtime compatibility is not required" a disagreement to comment #56,
as stated?  It seems that maybe everyone is in agreement, and just doesn't
realize it yet?

If I understand what Ceki is proposing correctly, it is exactly what I I've
been thinking about all along.  Changing the method signature in the API from
Object[] to Object... in support of varargs will maintain compatibility without
change necessary in any implementations.  (Internally, Java still treats both
as Object[].)

As part of this (I haven't tested this yet), I would guess this approach would
mean the 4 extra overloads per method in the Logger API could actually be
eliminated: (String, Object), (String, Object, Object), (Marker, String,
Object), and (Marker, String, Object, Object).  This would be done for trace,
debug, info, warn, and error, resulting in 20 (4*5) less methods in the API and
required to be implemented in any implementations, without any loss of
functionality.  Unfortunately, I'm guessing any calling code to these methods
won't be able to dynamically rebind to the varargs call, as the n-argument
overload would be referenced in the bytecode.  I'd propose at least marking
them as deprecated, hoping that they could actually be removed someday (2.0?). 
However, I'm also assuming that these overloads would continue to be preferred
for call binding over the varargs method, resulting in false deprecation
warnings.  So ignore this paragraph for the near future, but keep it in mind
for any API-breaking versions.

This probably isn't even enough change to warrant bumping the version all the
way to 2.0.  Ceki previously proposed 1.6.  The only impact is that the new API
will only be usable from Java 1.5 or higher, which it seems everyone agrees is
a non-issue.  If necessary for any absolutely critical bugs, an additional
revision or 2 could still easily be made to the "SLF4J 1.5 branch".

This overall approach requires 0 changes in both SLF4J implementations as well
as calling code, without having to change any imports or class names.  I may
have several classes that already heavily use "org.slf4j.Logger".  This
approach means that I don't have to add a 2nd import or add an additional
wrapper, etc., to have varargs support - which is the focus of this bug.

The issue with logging of handling exceptions along with this (bug #70) should
still be able to be addressed independently of this decision.  As shown
elsewhere, both in that bug report and the comments above, there are solutions
proposed to address this - also without required API changes.

I wouldn't want to be one using or encouraging a fork of SLF4J.  SLF4J seems to
be doing very well as a replacement for log4j, commons logging, and other
implementations.  I am very thankful for this.  In my opinion, it is the best
currently available for Java.  Part of this success is its own success: Since
so many other projects have been standardizing on SLF4J, it seldom needs to
become an "additional dependency" as it is already in the dependency tree. 
Competition with a fork would only hurt both.  Maintenance and keeping-up with
releases on any such fork are also important considerations.

In summary, comments #31, #56, and #58 all seem to be in agreement, and mean
that varargs support could be provided immediately and without any other
changes required.  Is there any reason to not proceed with this so the benefits
can begin to be used, and this bug can be closed?  This would not interfere
with future work on any of the other recommendations mentioned.


-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.