[slf4j-user] Re: Re: Varargs for Logger methods

[Ceki Gülcü]

At 01:25 PM 2/16/2006, Kostis Anagnostopoulos wrote:
>Thank you for your quick response,

You are welcome.

>At Thu Feb 16 10:58:57 CET 2006, Ceki Gülcü wrote:
> >....
> >Several experiments show that modifying o.s.Logger for varargs use would be
> >fairly straightforward. Existing clients would need to recompile their code
> >against the "upgraded" SLF4J API. No other changes would be necessary.
>
>Not even this!  Existing clients (those that are not using varags) would
>require no recompilation, unless the API changes in a non-compatible way
>(ie, some of its methods removed).
>So, lets leave the old ones (those with 2 object params) and
>just add the varag-ified ones.

I don't think adding varag-ified *overloaded* methods is possible. If it 
were possible, then what you suggest makes sense.

Take a simplified version of Logger:

public interface Logger {

   void log(String msg);
   void log(String msg, Object[] argArray);
   void log(String msg, Object ... args);
}

If you try to compile it, you will get:

# javac Logger.java
Logger.java:7: log(java.lang.String,java.lang.Object[]) is already defined 
in Logger
   void log(String msg, Object ... args);
        ^
1 error

>Only newly-written clients that take advantage of the new varg-ified API
>require compile.
>
>
> >However, it would *not* be possible to mix classes compiled against SLF4J
> >versions targeting 1.4  and those targeting 1.5.
>
>Why is that?
>Code compiled against 1.4 and non-varag SLF4J would also run
>in VM 1.5.
>Also if the varag-ified SLF4J API is modified compatible (see above),
>then it would run OK.
>
>Am i missing something here?

Have you overlooked the fact that varargs methods cannot be added on top of 
existing methods taking Object[] as their last argument.

Do you have any ideas on how to overcome this impossibility?

-- 
Ceki Gülcü