3 ms·

I would need a very strong reason to believe an internal team could build a more reliable and secure library than Log4J, and commit to support and maintain it f

I would need a very strong reason to believe an internal team could build a more reliable and secure library than Log4J, and commit to support and maintain it for as long as we need it, before I would think writing an internal log library was a good idea. Outside of very large software companies, developers add business value by writing things that don't already exist. Spending time rewriting third-party libraries has dubious business value.

bedatadriven 4y ago
Writing a reliable, secure function that writes messages to stdout might be all that a project needs. The risk of third party libraries is that they often do far more than needed for an individual project. Log4j got into trouble with a feature that supported remote lookups over LDAP.
- twblalock 4y ago
  > Writing a reliable, secure function that writes messages to stdout might be all that a project needs. That's how it starts. Then you need to log to file. Then you need to rotate those files. Then someone asks for a custom format. Eventually you end up with a crappy internal Log4J clone.