3 ms·

SLF4J basically won, IMO. Barring extremely specialized uses, there's not hugely compelling reasons to use anything else than slf4j-api as the logging interface

by koko775 14y ago

SLF4J basically won, IMO. Barring extremely specialized uses, there's not hugely compelling reasons to use anything else than slf4j-api as the logging interface to your backend of choice, I think. So there is a good default choice, and the "proper logging API" exists. Flume uses it, logback uses it, log4j is compatible with it, and it's compatible with pretty much everything, or you can write your own logger however you like. P.S. You sound really pissed about this. Do you have personal experience with logging frameworks?

bborud 14y ago
No, slf4j doesn't solve any problems: it just gives you different problems. What makes it twice as infuriating is that slf4j looks really promising until you realize that it is just more pig-lipstick, albeit in a different color than before. PS: That is because I am really pissed. If there is one thing I fucking hate it is all the time you have to spend trying to fit components together that use any one of the gazillion different logging frameworks and combinations of logging frameworks that are possible. But I'll give you that: I despise the shitheads behind log4j more than I despise the people behind slf4j. Logging sucks in Java.
- koko775 14y ago
  Specifics, please. I just implemented a logging backend for slf4j on Android in roughly ~1 hour with virtually no prior knowledge other than generally how to use slf4j and how to use Android's Log class. It just worked, and it was pretty darn simple, and now I have fancy log messages. I even customized the tags so that instead of com.example.some.path.to.Something, I can summarize that to c.e.s.p.to.Something.
  - bborud 14y ago
    Writing a logging backend for slf4j isn't hard. Anyone unable to do that should not be programming. Trying to figure out how to a) get lots of components that rely on wildly different logging frameworks and even multiple versions of the same logging frameworks and b) try to distill that into common practices in an engineering organization, is hard. In part because you have to spend two hours explaining the problems we've been through every time someone thinks all these problems have a 5 minute fix. (And the slf4j technique of placing a bridge in the class path and hoping for the best is just priceless. That deserves an entire hour of slow clap)
    - koko775 14y ago
      Okay, now we're getting somewhere, but as someone who has used Java more client-side than server-side, I'm not familiar with the problems everyone's else been through. I would love for you to enlighten me, if you could! Also, what would you substitute in place of StaticLoggerBinder? It did strike me as somewhat janky to rely on a class with a matching name and class just existing.
      - bborud 14y ago
        The problem is not software. The problem is people. Rather than trying to explain the problem (which most people who work on logging struggle to see), let me outline how you determine when the problem is either solved or absent. The problem is solved when people like me (a hands-on system architect who writes code and tries to make decisions on behalf of a number of developers) do not have to think about logging APIs, facades or backends anymore. When nobody in my organization has to spend time trying to resolve the conflicts that arise from different logging technologies (and different versions of same technologies) being in use in the same system. We have an example of that in Java: the collection classes. For most bread-and-butter uses Java has List, Map and Set types that people can just use. They are well designed, well documented and you can count on them to be available at no extra cost. It is unusual for a non-mad() Java programmer to feel the need to introduce extra dependencies for simple lists, sets, maps etc. You most likely are not going to feel the pain of logging chaos if you are writing a single application. If you try to make decisions on behalf of 50+ projects, some of which rely on an obscene number of libraries, that pain will manifest itself every day and you will re-live the same pointless discussions and get the same pointless advice over and over and over. Hope this sheds some light on why I think what I think. () there are idiots who depend on third party implementations where the types in J2SE would suffice.

by koko775 14y ago

bborud 14y ago

No, slf4j doesn't solve any problems: it just gives you different problems. What makes it twice as infuriating is that slf4j looks really promising until you realize that it is just more pig-lipstick, albeit in a different color than before. PS: That is because I am really pissed. If there is one thing I fucking hate it is all the time you have to spend trying to fit components together that use any one of the gazillion different logging frameworks and combinations of logging frameworks that are possible. But I'll give you that: I despise the shitheads behind log4j more than I despise the people behind slf4j. Logging sucks in Java.

koko775 14y ago
Specifics, please. I just implemented a logging backend for slf4j on Android in roughly ~1 hour with virtually no prior knowledge other than generally how to use slf4j and how to use Android's Log class. It just worked, and it was pretty darn simple, and now I have fancy log messages. I even customized the tags so that instead of com.example.some.path.to.Something, I can summarize that to c.e.s.p.to.Something.
- bborud 14y ago
  Writing a logging backend for slf4j isn't hard. Anyone unable to do that should not be programming. Trying to figure out how to a) get lots of components that rely on wildly different logging frameworks and even multiple versions of the same logging frameworks and b) try to distill that into common practices in an engineering organization, is hard. In part because you have to spend two hours explaining the problems we've been through every time someone thinks all these problems have a 5 minute fix. (And the slf4j technique of placing a bridge in the class path and hoping for the best is just priceless. That deserves an entire hour of slow clap)
  - koko775 14y ago
    Okay, now we're getting somewhere, but as someone who has used Java more client-side than server-side, I'm not familiar with the problems everyone's else been through. I would love for you to enlighten me, if you could! Also, what would you substitute in place of StaticLoggerBinder? It did strike me as somewhat janky to rely on a class with a matching name and class just existing.
    - bborud 14y ago
      The problem is not software. The problem is people. Rather than trying to explain the problem (which most people who work on logging struggle to see), let me outline how you determine when the problem is either solved or absent. The problem is solved when people like me (a hands-on system architect who writes code and tries to make decisions on behalf of a number of developers) do not have to think about logging APIs, facades or backends anymore. When nobody in my organization has to spend time trying to resolve the conflicts that arise from different logging technologies (and different versions of same technologies) being in use in the same system. We have an example of that in Java: the collection classes. For most bread-and-butter uses Java has List, Map and Set types that people can just use. They are well designed, well documented and you can count on them to be available at no extra cost. It is unusual for a non-mad() Java programmer to feel the need to introduce extra dependencies for simple lists, sets, maps etc. You most likely are not going to feel the pain of logging chaos if you are writing a single application. If you try to make decisions on behalf of 50+ projects, some of which rely on an obscene number of libraries, that pain will manifest itself every day and you will re-live the same pointless discussions and get the same pointless advice over and over and over. Hope this sheds some light on why I think what I think. () there are idiots who depend on third party implementations where the types in J2SE would suffice.