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

[Ceki Gulcu]

Jörn Huxhorn wrote:
> 
> Are you serious?

I was.

> I once heard a lecture on logging and the prof said that the main objective
> of any logging framework must be to not break the application it is logging.

Absolutely.

>>From this point of view - that I absolutely share - the quality of the slf4j
> framework would be lower after applying toString for arrays than before
> since now there is a real possibility to crash an application by simply
> issuing a log message.

Agreed.

> It's also not our task to define that recursive arrays are a bug. With the
> previous implementation a log message containing such an array would have
> worked, with the new implementation it would crash the application.

Agreed.

> Whether something like recursive arrays makes sense is purely application
> specific.

Agreed.

> Beside that, the fix is really simple...

OK, you've got me convinced. Consider the fix done.

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.

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 
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.

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

-- 
Ceki Gülcü