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

[bugzilla-daemon at pixie.qos.ch]

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





------- Comment #11 from joern at huxhorn.de  2007-10-11 00:38 -------
No problem at all :)

But it's not my only solution-proposal for this problem - perhaps you like this
one better...

I can fully understand that the 1.4.4.5 versus 1.4.4 is "magic" and probably
not very intuitive - and that's really a no-no.

I choose it because of it's simplicity when used with Maven 2, i.e. a .5 higher
version number overrides the version without .5, i.e. I was lazy and also a
little bit proud of this "maven hack" :).

It would also be possible to use slf4j-api-jdk15 as artifactId of
slf4j-api-jdk15/pom.xml instead of slf4j-api and leave the version the same as
slf4j-api. This would remove the black-magic part (which is surely a very good
thing ;)) and would also clearly show the jdk15 dependency.

It would be included in maven like this

<dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api-jdk15</artifactId>
        <version>1.4.4</version>
        <scope>compile</scope>
        <!-- 
        replacement for slf4j-api below
        -->
</dependency>
<dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>1.4.4</version>
        <scope>provided</scope>
        <!-- 
        overrides transitive dependencies,
        replaced by slf4j-api-jdk15 above
        -->
</dependency>

instead of just

<dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>1.4.4.5</version>
        <!-- 
        Automagically replaces JDK14 1.4.4 with JDK15 1.4.4.5.
        I completely agree that this is a trick/hack... ;)
        -->
        <scope>compile</scope>
</dependency>

but this is really a small price to pay compared to the increased transparency
of what's actually happening.

It would be a *lot* more obvious that compiling against that version requires
jdk15 at *both* compile- and runtime.
slf4j-api-jdk15 is only meant for projects that depend on 1.5 anyway and on
purpose - so modules that want to stay 1.4 compatible will simply stick to
slf4j-api.

It would then also be possible to include slf4j-api-jdk15/pom.xml in
slf4j-parent because it has a unique artifactId in contrast to my previous
proposal.

All the binding would keep their slf4j-api dependency and the same is true for
other third-party modules that use slf4j-api right now.

slf4j-api-jdk15 is a JDK1.5-only drop-in replacement for slf4j-api and not vice
versa. If you *want* to use varargs, you *must* use 1.5. And if you use 1.5
anyway you *can* use varargs with slf4j by using slf4j-api-jdk15 instead of
slf4j-api.

> Your patch demonstrates that we could modify the Logger interface to
> use varargs without impacting existing users (as long as they use JDK
> 1.5).  That's a considerable plus. However, we cannot replace:
> 
> 1) debug(String, Object)
> 2) debug(String, Object, Object)
> 3) debug(String, Object[])
> 
> with just:
> 
> debug(String, Object...)
> 
> Only the third method can be replaced. The first two have to be kept
> as is. From my point of view as a SLF4J developer that's a pity.

That's true. Methods 1) and 2) must stay to provide binary compatibility.
Otherwise it would not be possible to stay compatible with third-party modules
that depend on slf4j-api - which was my main objective!

slf4j-api-jdk15 is by no means a full jdk15 redesign of slf4j-api. I wouldn't
dare ;) and I don't think this is an option in the near future because it would
really break a lot of code.

Every depending module would have to be recompiled!!

I don't think that the removal of 1) and 2) for "aesthetic reasons"* is worth
breaking binary compatibility at all.
Granted, it avoids some code duplication, but this could also be achieved by
calling 3) in 1) and 2).
I wouldn't do this either since it would be slower anyway (creation of an
additional Object[] if 1) and 2) call 3) as well as the implicit creation of an
Object[] in case of debug(String, Object...) (Object... is only syntactic sugar
for new Object[]{} )).

So you could also see 1) and 2) as optimized special-cases of 3) because that
is what they are! :D

The sole purpose of slf4j-api-jdk15 was to enable varargs for jdk15-developers
*right* *now* with a minimal impact for both slf4j-users and -developers. I
especially like that I could avoid any code-duplication (well, beside
Logger.java, obviously, but interfaces don't really count as code :) ).

I really hope that this proposal is more to your liking.

This way it's not any more complex than

<dependency>
        <groupId>commons-logging</groupId>
        <artifactId>commons-logging</artifactId>
        <scope>provided</scope>
</dependency>
<dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>jcl104-over-slf4j</artifactId>
        <scope>runtime</scope>
</dependency>

or

<dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <scope>provided</scope>
</dependency>
<dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>log4j-over-slf4j</artifactId>
        <scope>runtime</scope>
</dependency>

which an slf4j-user is already comfortable with.

Thanks for reading that far,
Joern.

* please don't get the "aesthetic reasons" wrong. It's not irony or sarcasm at
all. I can fully understand your desire for a clean, minimal interface but I
think it's just too late. Breaking binary compatibility is really a "bad
thing"...


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