[slf4j-dev] svn commit: r1086 - in slf4j/trunk/slf4j-api/src: main/java/org/slf4j/helpers test/java/org/slf4j/helpers

[Jörn Huxhorn]

On Mon, Aug 4, 2008 at 10:13 AM, Ceki Gulcu <listid at qos.ch> wrote:
>
> OK, you've got me convinced. Consider the fix done.


Nice. ;)

>
>
> For the sake of this and future discussions, let me mention that one of
> SLF4J's
> main selling points is its simplicity. Compared to JCL, SLF4J way of
> binding to
> the underlying logging system is outrageously simple. It covers fewer use
> cases
> than JCL. But, as SLF4J  is simpler it is also more robust and as you
> pointed
> out, robustness must be an essential characteristic of a logging framework.
> In
> short, simplicity of implementation matters.
>

To quote Albert Einstein: "Make everything as simple as possible, but not
simpler."
I *love* the way SLF4J/logback binding is done. The same is the case for the
xxx-over-slf4j stuff.


> More to the point, the bug under consideration is not insidious. If a
> client has
>  cyclical arrays and attempts to log them, their application will crash
> immediately with a clear pointer to MessageFormatter.deeplyAppendParameter.
> They


Hehe, are you really sure about this?
Granted, I would do that. And you would do that, too, if you had a problem
like this in some library you're using... but I know several developers that
would be *sure* that the problem must somehow be their fault, searching
hours and hours, while the logging they would need to analyze the problem
would be broken ;)

I suggested slf4j and logback to a certain guy at TU Darmstadt so quite some
very fresh students with very limited experience are using it right now to
log their very first java programs...


>
> will complain about the lack of support for cyclical arrays and we will
> quickly
> provide a fix. Here, I am assuming that non-cyclical arrays during
> development
> do not suddenly become cyclical in production. So instead of supporting
> cyclical
> arrays today, we can provide them tomorrow, but only when a user asks for
> it.
> This is just an application of the "1$ Today Is Worth More Than 1$
> Tomorrow"
> principle -- avoiding adding features that users don't seem to need today
> and
> hence saving a few cycles of my development time and more significantly a
> few
> brain cycles of people trying to read SLF4J code.
>

I understand your point. Feature creep can be a big problem...

In my opinion there are roughly three kinds of bugs.
I'll give you an example for every one:

1.) Bugs like this one or the original recursive Marker problem that could
result in an application crash, no matter how likely or unlikely the
scenario for the crash is.
They need to be fixed, ASAP, after identification of the problem and after
writing a unit test, of course. I would not call the prevention of a crash
an additional feature but a fix of a defect instead. Those are, in my
opinion, showstoppers.

2.) A problem like the one I described in my last comment at
http://bugzilla.slf4j.org/show_bug.cgi?id=76
This is a situation where I see a problem lurking in the future. I tend to
fix such problems anyway just to get them out of my head and prevent future
troubles. Chances are that I won't have very much time to spare when such a
problem manifests so I'll fix them when I stumble over them.

3.) An inconsistency like http://bugzilla.slf4j.org/show_bug.cgi?id=93
I don't really care if this behavior is changed or not. I just wanted to let
you know - so that you *do* know. I, personally, like consistency but this
"bug" is really irrelevant. No harm can be done by this problem.

To quote The Pragmatic Programmer: "Don't leave broken windows."

Concerning bugs like 1.) I'll now try to argue from a different direction:
If slf4j/Logback would tear down our web application which is supposed to be
online 99.9% then I would be the one with the "chopped off head" because I
was the one that suggested the transition away from commons.logging and
log4j over to slf4j/log4j and later slf4j/logback. While the chopped off
head is surely an exaggeration there are a lot of people that are quite
dependent on the proper function of slf4j right now.

So this is also a story about trust. People trust you.
Every bug that manifests in an actual application removes a little bit of
trust so it's always a good thing to fix a bug *before* it's actually doing
harm to someone. I'm not sure about the $1 metaphor in that case.

And last but not least, concerning "we will quickly provide a fix":

I submitted http://bugzilla.qos.ch/show_bug.cgi?id=148 in April, including a
suggested fix, and it hasn't been included into logback yet, neither was
there a new version of logback since March.

This isn't meant as criticism at all.

Really ;)

I just wanted to use it as an example that "quick" can be quite relative.


> However, as you observed, the fix is simple and elegant, so there is no
> point in
> procrastinating the implementation of a simple solution.
>
> Thank you.

Again, as I said in previous mails, I hope you don't get me wrong as I'm
essentially a big fan of your software. I'll stop making remarks about that
from now on, ok? ;)
English isn't my first language so there is a certain possibility that
something might sound harsh even though it's not meant to be that way.

Regards,
Joern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20080804/cb6f1a22/attachment.htm>