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ü
_______________________________________________
user mailing list
[email protected]
http://slf4j.org/mailman/listinfo/user
