3 ms·

Avoid frameworks and libraries whenever possible. The last time I benchmarked java.util.logging though, it lost out to log4j by a wide enough margin. Has anyon

by pdevr 5y ago

Avoid frameworks and libraries whenever possible. The last time I benchmarked java.util.logging though, it lost out to log4j by a wide enough margin. Has anyone done any benchmarking lately?

HatchedLake721 5y ago
Yes, let’s reinvent the wheel, waste time and resources every time! Who needs decades of battle tested, proven methods and tools? Who needs thousands of human hours behind thousands of GitHub issues and pull requests? Let’s do everything from scratch! Hm, why is there JavaScript fatigue and 10 new frameworks every month?
- kreeben 5y ago
  Didn't log4j show us that "battle tested, proven" means nothing?
  - coldcode 5y ago
    Nothing in programming is proven since everything changes all the time. Otherwise we would still be programming in Cobol, Fortran, LISP and APL without changes from the 1950's. It's like saying tanks from WW1 were good enough to last forever. Change means you have to prove things over and over, and generally the pace of change is too fast for anything to be proven before it is obsolete.
  - csmpltn 5y ago
    > "Didn't log4j show us that "battle tested, proven" means nothing?" Exactly the kind of comment you'd get from an inexperienced junior developer. There are bugs in every software stack, and bugs can be fixed. We fix the bugs, and we move on in life.
    - bluesnowmonkey 5y ago
      That’s an ad hominem attack. It shuts down conversation rather than encouraging it. Not the level of discourse we should be seeing on here. Everybody is allowed to have an opinion regardless of their background. Anyway I have >20 years of experience and say kreeben has a point. The popularity of this library is working against it, preventing it from reversing bad decisions, and multiplying the harm. Sometimes it’s worthwhile in the long run to throw away the “battle tested” thing in favor of a newer, simpler alternative.
      - csmpltn 5y ago
        > "The popularity of this library is working against it, preventing it from reversing bad decisions, and multiplying the harm. Sometimes it’s worthwhile in the long run to throw away the “battle tested” thing in favor of a newer, simpler alternative." You can say that about anything, I don't get your point. Talk about not adding substance to the conversation... Some bugs are difficult to fix, and sometimes how we fix something has to be weighed against things like backwards-compatability. That a certain fix makes sense to you, doesn't mean it's a done story. It's not dead weight being dragged around - it's the consequence of having millions of enterprises all over the world directly depend on your software - so you actually have to spend the time finding a proper solution first, not just improvising. Your customers are banks, healthcare, goverments, schools, and so on. "Move fast and break things" doesn't work here. 20 years in this industry, so you should know better.
    - dimgl 5y ago
      > Exactly the kind of comment you'd get from an inexperienced junior developer. This is unnecessary
      - csmpltn 5y ago
        > "This is unnecessary" You mean, like kreeben crapping on the work of hundreds of log4j contributors over the years by dismissing it as "worth nothing"?
        detaro 5y ago
        They didn't say their work is worth nothing, but that the label doesn't mean much. And even if they did, that's still a level better than your comment. And even if it wasn't, "they said something bad so now I'm going to insult them too" is not how discussions are supposed to work here.
  - aflag 5y ago
    Finding and fixing this bug is part of the battle testing.
    - lanstin 5y ago
      Truthfully most log libraries are not going to have such a flaw.
      - aflag 5y ago
        That may be true, but that doesn't mean that battle tested means nothing. There are plenty other logging libraries that have also been thoroughly tested. If you look for obscure logging libraries in c, c++ and even bash I wouldn't be surprised if you found rce bugs. In Java it's probably less common.
  - whoisthemachine 5y ago
    "Program testing can be used to show the presence of bugs, but never to show their absence!" - Djikstra... meaning, just because something is battle-tested, doesn't mean that we have proven it has no defects.
- pdevr 5y ago
  Not every time, "whenever possible".
stjohnswarts 5y ago
I'm sure there's 0 chance your custom logger won't have any bugs either? At best you get some security through obscurity, but your chances go way up on writing a bug ridden custom library. No software selection paradigm will be 100% secure, that's the one guarantee you'll have.

by pdevr 5y ago

Avoid frameworks and libraries whenever possible. The last time I benchmarked java.util.logging though, it lost out to log4j by a wide enough margin. Has anyone done any benchmarking lately?

HatchedLake721 5y ago

Yes, let’s reinvent the wheel, waste time and resources every time! Who needs decades of battle tested, proven methods and tools? Who needs thousands of human hours behind thousands of GitHub issues and pull requests? Let’s do everything from scratch! Hm, why is there JavaScript fatigue and 10 new frameworks every month?

kreeben 5y ago
Didn't log4j show us that "battle tested, proven" means nothing?
- coldcode 5y ago
  Nothing in programming is proven since everything changes all the time. Otherwise we would still be programming in Cobol, Fortran, LISP and APL without changes from the 1950's. It's like saying tanks from WW1 were good enough to last forever. Change means you have to prove things over and over, and generally the pace of change is too fast for anything to be proven before it is obsolete.
- csmpltn 5y ago
  > "Didn't log4j show us that "battle tested, proven" means nothing?" Exactly the kind of comment you'd get from an inexperienced junior developer. There are bugs in every software stack, and bugs can be fixed. We fix the bugs, and we move on in life.
  - bluesnowmonkey 5y ago
    That’s an ad hominem attack. It shuts down conversation rather than encouraging it. Not the level of discourse we should be seeing on here. Everybody is allowed to have an opinion regardless of their background. Anyway I have >20 years of experience and say kreeben has a point. The popularity of this library is working against it, preventing it from reversing bad decisions, and multiplying the harm. Sometimes it’s worthwhile in the long run to throw away the “battle tested” thing in favor of a newer, simpler alternative.
    - csmpltn 5y ago
      > "The popularity of this library is working against it, preventing it from reversing bad decisions, and multiplying the harm. Sometimes it’s worthwhile in the long run to throw away the “battle tested” thing in favor of a newer, simpler alternative." You can say that about anything, I don't get your point. Talk about not adding substance to the conversation... Some bugs are difficult to fix, and sometimes how we fix something has to be weighed against things like backwards-compatability. That a certain fix makes sense to you, doesn't mean it's a done story. It's not dead weight being dragged around - it's the consequence of having millions of enterprises all over the world directly depend on your software - so you actually have to spend the time finding a proper solution first, not just improvising. Your customers are banks, healthcare, goverments, schools, and so on. "Move fast and break things" doesn't work here. 20 years in this industry, so you should know better.
  - dimgl 5y ago
    > Exactly the kind of comment you'd get from an inexperienced junior developer. This is unnecessary
    - csmpltn 5y ago
      > "This is unnecessary" You mean, like kreeben crapping on the work of hundreds of log4j contributors over the years by dismissing it as "worth nothing"?
      - detaro 5y ago
        They didn't say their work is worth nothing, but that the label doesn't mean much. And even if they did, that's still a level better than your comment. And even if it wasn't, "they said something bad so now I'm going to insult them too" is not how discussions are supposed to work here.
- aflag 5y ago
  Finding and fixing this bug is part of the battle testing.
  - lanstin 5y ago
    Truthfully most log libraries are not going to have such a flaw.
    - aflag 5y ago
      That may be true, but that doesn't mean that battle tested means nothing. There are plenty other logging libraries that have also been thoroughly tested. If you look for obscure logging libraries in c, c++ and even bash I wouldn't be surprised if you found rce bugs. In Java it's probably less common.
- whoisthemachine 5y ago
  "Program testing can be used to show the presence of bugs, but never to show their absence!" - Djikstra... meaning, just because something is battle-tested, doesn't mean that we have proven it has no defects.
pdevr 5y ago
Not every time, "whenever possible".

stjohnswarts 5y ago

I'm sure there's 0 chance your custom logger won't have any bugs either? At best you get some security through obscurity, but your chances go way up on writing a bug ridden custom library. No software selection paradigm will be 100% secure, that's the one guarantee you'll have.