4 ms·

Seems like you're disagreeing on the basis of personal development rather than whether it makes sense for any given project. I think at that point it depends on

Seems like you're disagreeing on the basis of personal development rather than whether it makes sense for any given project. I think at that point it depends on whether you're primarily coding to learn or to make software

shepherdjerred 5y ago
By the same token why would you roll your own instead of using a tried and true library that any experienced Java developer already knows?
- teitoklien 5y ago
  You’re practically right, But if your team isn't constantly changing then running your custom solution for at-least more simpler things like logging is better. Because otherwise you have to depend on skills of a third party library maintainer you have no communication with or contract agreement with, to protect his/her codebase from getting security backdoors, which other malicious actors will constantly try to inject it with, if the library is known to be used by various large enterprises. Coding with third party libraries is about trust, for simpler functions and packages its usually worth it long term to code it in-house. It’s easier to maintain, only comes with features you need and you’re always aware of what capabilities your code has. I’m everyday impressed how relatively less npm with node, etc get hacked, considering they use additional third-party libraries for 4 liner functions too.
- jallen_dot_dev 5y ago
  > why would you roll your own instead of using a tried and true library For one, the very reason we are all in this thread right now.
  - thebean11 5y ago
    Plenty of "roll your own x"s have critical security bugs too, they just don't make the front page of HN. Do you really think, in general, roll your own is safer?
    - jallen_dot_dev 5y ago
      Not in general. Your own cryptography implementation? Hell no. Your own simple logging solution that doesn't need anything fancy from log4j? Probably.
      - thebean11 5y ago
        Simple is..a pretty big stretch for Log4j, even just taking the subset of features that your average medium-sized company would use.
- asddubs 5y ago
  put in general terms, to minimize complexity, and to a lesser extent, increase control. I'm not saying it's always worth it to do that no matter what, but for smaller things like logging, if you don't have any hugely complex needs (i.e. it won't be much effort to maintain your own solution), I would personally always prefer an in-house solution. It's all a function of effort, of course.
- staticassertion 5y ago
  Because it apparently is absurdly complicated for a task I can solve with 'println'.
  - coredog64 5y ago
    Java since 5 has included it’s own logging class. It doesn’t have as many features as log4j, but it also doesn’t load classes via JNDI.
    - xxs 5y ago
      java 5 - erm. java 1.4... and truth be told I'd prefer them over any other logging solution. Yet, java.util.logging has has quite a lot of vulnerabilities, itself.

shepherdjerred 5y ago

By the same token why would you roll your own instead of using a tried and true library that any experienced Java developer already knows?

teitoklien 5y ago
You’re practically right, But if your team isn't constantly changing then running your custom solution for at-least more simpler things like logging is better. Because otherwise you have to depend on skills of a third party library maintainer you have no communication with or contract agreement with, to protect his/her codebase from getting security backdoors, which other malicious actors will constantly try to inject it with, if the library is known to be used by various large enterprises. Coding with third party libraries is about trust, for simpler functions and packages its usually worth it long term to code it in-house. It’s easier to maintain, only comes with features you need and you’re always aware of what capabilities your code has. I’m everyday impressed how relatively less npm with node, etc get hacked, considering they use additional third-party libraries for 4 liner functions too.
jallen_dot_dev 5y ago
> why would you roll your own instead of using a tried and true library For one, the very reason we are all in this thread right now.
- thebean11 5y ago
  Plenty of "roll your own x"s have critical security bugs too, they just don't make the front page of HN. Do you really think, in general, roll your own is safer?
  - jallen_dot_dev 5y ago
    Not in general. Your own cryptography implementation? Hell no. Your own simple logging solution that doesn't need anything fancy from log4j? Probably.
    - thebean11 5y ago
      Simple is..a pretty big stretch for Log4j, even just taking the subset of features that your average medium-sized company would use.
asddubs 5y ago
put in general terms, to minimize complexity, and to a lesser extent, increase control. I'm not saying it's always worth it to do that no matter what, but for smaller things like logging, if you don't have any hugely complex needs (i.e. it won't be much effort to maintain your own solution), I would personally always prefer an in-house solution. It's all a function of effort, of course.
staticassertion 5y ago
Because it apparently is absurdly complicated for a task I can solve with 'println'.
- coredog64 5y ago
  Java since 5 has included it’s own logging class. It doesn’t have as many features as log4j, but it also doesn’t load classes via JNDI.
  - xxs 5y ago
    java 5 - erm. java 1.4... and truth be told I'd prefer them over any other logging solution. Yet, java.util.logging has has quite a lot of vulnerabilities, itself.