[slf4j-user] varargs

Ceki Gülcü listid at qos.ch
Fri Nov 10 22:40:53 CET 2006


Hello Martin,

If we change only one method (per level) in the Logger interface, that
is, from

   public void debug(String format, Object[] objArray);

to

   public void debug(String format, Object... );

then, interestingly enough, there is a high level of inter-operability
between the two versions. If we call, the former version SLF4J-1 and
the latter SLF4J-2, then clients compiled against SLF4J-1 run with
SLF4J-2 (under JDK 1.5). In addition,clients compiled against SLF4J-2
run with SLF4J-1 (under JDK 1.5).

In other words, the two SLF4J versions would be interchangeable as
long as then ran under JDK 1.5.

If in a later date we decide to change the interface to use varargs,
existing clients would not suffer as long as the target JDK is 1.5.

I don't think SLF4J could switch to JDK 1.5 today. However, if and
when we switch, existing clients would not be affected, provided the
host JVM is 1.5.

As for your question about dropping support for JDK 1.4, I would not
want to alienate existing clients. Maybe I should start a new branch
targeting JDK 1.5 while continuing to maintain the old one.

Cheers,


At 12:16 PM 11/10/2006, Martin Gilday wrote:
>Sounds like the most reasonable solution.
>The only other alternative I can think of is to have a "Logger5"
>inteface which entends the current Logger with the varargs method on it,
>and then have an extended class for each implementation which adds the
>new method on.  These could be stored in an additional artifact similar
>to how Opensymphony have an xwork-tiger set of extensions.  This would
>require users to use an alternative interface and mean lots of
>additional classes to maintain, so it is far from ideal.  Changing the
>base JDK requirement seems the easiet solution, but are you not worried
>about alienating those who still must work to 1.4?

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch




More information about the slf4j-user mailing list