4 ms·

NO! Sorry, let me rephrase that: FUCK NO! What Java needs is for all the fucking logging separatists to grow the fuck up and accept that for the greater good

by bborud 14y ago

NO! Sorry, let me rephrase that: FUCK NO! What Java needs is for all the fucking logging separatists to grow the fuck up and accept that for the greater good we need a single solution for this -- and for Oracle to grow a brain, and to give Java a proper logging API and a good default implementation so we can stop wasting more energy on all the fucking logging frameworks for Java that do not work. Anyone not working towards giving J2SE a good logging API and at least one good implementation that can be distributed with the JDK can go to hell.

IsaacL 14y ago
I only briefly worked in a Java dev shop as an intern, but I remember coming across Apache Commons Logging, and seeing the idea of an abstraction framework for logging frameworks an example of the "architecture astronautism" that infests Java. However, I do realise that the Java ecosystem is often complex for a reason (or, "simpler" languages and frameworks are often too simple). Is there a reason there are so many logging frameworks? What different needs do they solve?
- exabrial 14y ago
  No, there really isn't a need for all of them. SLF4J solves 100% of the problems 95% of the time. The problem is Apache's "Not invented here" syndrom. Commons-logging, Log4j, developers need to just abandon their projects and work on SLF4J. BTW "architecture astronautism" great term. I <3 Java, it has a culture of overengineering, in which I do not participate.
  - grobmeier 14y ago
    slf4j is a facade. It does not do much alone. logback / log4j2 are 2 implementations of the slf4j facade. log4j2 is a community driven project and it is maintained with Apache License 2.0. It addresses some issues of logback. If you run into this issues in production, you can switch to log4j2, given that you are using slf4j (which is the recommendation). commons-logging is pretty dead, and nobody makes a deal about it. It has not been updated for around 5 yrs. You clearly need to understand the difference between slf4j and logback/log4j2. And you should learn more about what the Apache Software Foundation is doing. I consider it better not to trust a single company when it comes to important things. It has often proven in the past.
  - bowyakka 14y ago
    Whilst I am not a fan of the logging pain in java, not invented here would apply to anyone thats not log4j since they were really the first to get properly started.
    - bborud 14y ago
      Nobody cares who was first. The right thing to do would have been to focus on getting j.u.l right and then be a grown-up about it and ditch log4j. Apache fucked up and Sun fucked up. And we all lose.
    - koko775 14y ago
      The creator of slf4j and logback originally created log4j, so "Not Invented Here" is literally not true as the inventor invented those three libraries.
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)

by bborud 14y ago

IsaacL 14y ago

I only briefly worked in a Java dev shop as an intern, but I remember coming across Apache Commons Logging, and seeing the idea of an abstraction framework for logging frameworks an example of the "architecture astronautism" that infests Java. However, I do realise that the Java ecosystem is often complex for a reason (or, "simpler" languages and frameworks are often too simple). Is there a reason there are so many logging frameworks? What different needs do they solve?

exabrial 14y ago
No, there really isn't a need for all of them. SLF4J solves 100% of the problems 95% of the time. The problem is Apache's "Not invented here" syndrom. Commons-logging, Log4j, developers need to just abandon their projects and work on SLF4J. BTW "architecture astronautism" great term. I <3 Java, it has a culture of overengineering, in which I do not participate.
- grobmeier 14y ago
  slf4j is a facade. It does not do much alone. logback / log4j2 are 2 implementations of the slf4j facade. log4j2 is a community driven project and it is maintained with Apache License 2.0. It addresses some issues of logback. If you run into this issues in production, you can switch to log4j2, given that you are using slf4j (which is the recommendation). commons-logging is pretty dead, and nobody makes a deal about it. It has not been updated for around 5 yrs. You clearly need to understand the difference between slf4j and logback/log4j2. And you should learn more about what the Apache Software Foundation is doing. I consider it better not to trust a single company when it comes to important things. It has often proven in the past.
- bowyakka 14y ago
  Whilst I am not a fan of the logging pain in java, not invented here would apply to anyone thats not log4j since they were really the first to get properly started.
  - bborud 14y ago
    Nobody cares who was first. The right thing to do would have been to focus on getting j.u.l right and then be a grown-up about it and ditch log4j. Apache fucked up and Sun fucked up. And we all lose.
  - koko775 14y ago
    The creator of slf4j and logback originally created log4j, so "Not Invented Here" is literally not true as the inventor invented those three libraries.

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)