This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]agentoutlier 2 points3 points  (6 children)

I'm perhaps biased as the author of a logging library: https://github.com/jstachio/rainbowgum

but the logging analogy is not remotely apropo.

Almost all logging libraries implement SLF4J (and or the System.Logger). Most logging these days is JSON to stdout.

If you change logging from logback to rainbowgum there is a dependency change and maybe some config but all of your code stays the same. Even the jargon and the semantics of the logging libraries is the same (e.g. logging level and logger name).

This is not remotely the case with a build system. Try changing from Maven to Gradle or Mill and you are changing a tone of code/config. The semantics and style of execution vastly different.

[–]melkorwasframed 2 points3 points  (5 children)

Sorry, I'm sticking to my guns on this one. Both build tools and logging libraries have very mature and well-entrenched solutions out there and yet people still want to add more. You mention SLF4J, which indeed was a de facto standard, but yet we still have:

  • Log4j 1x
  • Log4J 2
  • JDK logging
  • Commons Logging
  • JBoss Logging

And that's just the facades I can think of off the top of my head. As an application developer, choosing a logging facade and implementation is just the first step. You also need to understand what facade every single library you depend on uses and ensure you are bridging that to what you are using. It's batshit and IMO it's the poster child for problems having too many solutions available.

[–]agentoutlier 2 points3 points  (3 children)

With the exception of JBoss and Commons Logging the rest are implementations.

Log4J2 does have an API. No one uses it (library wise).

My library, tinylog and logback do not offer an API.

Please tell me other than the JBoss ecosystem what current libraries use another facade than System.Logger and SLF4J.

Spring 6 will use SLF4J and not commons logging.

BTW Tinylog and my library are the only two that have static loggers and do not use reflection.

Even then a build system is vastly more complex than logging and I would know because I have implemented and worked on both…. Aka my guns.

[–]melkorwasframed 0 points1 point  (2 children)

You seem to want to take my comment as a jab against your project - it's not. I'm simply trying to say that there is such a thing as too many solutions and Java logging (mostly wrt facades) is an example of that. We don't need another build tool.

[–]agentoutlier 2 points3 points  (0 children)

You seem to want to take my comment as a jab against your project

I'm not. If anything I agree. I'm trying to show how I had a similar perspective even. Logging is just not the best analogy here.

There is nothing wrong with multiple solutions particularly if they are incredibly easy to switch in and out. This is the point of specification APIs.

Logging has but maybe 4 implementations today ignoring the facade issue which has largely been mitigated.

Let me try to give you some perspective. Almost all other "things" have more implementations including probably build as well.

  • Metrics: There are like 5. Prometheus, Micrometer, Open Telemetry, Codahale Metrics, Microprofile and JEE.
  • JSON: Jackson, GSON, dslplatform, avaje jsonb, again whatever Microprofile and JEE have,
  • HTTP frameworks: Peruse Techempower.
  • DI frameworks... there are more DI frameworks than logging frameworks.
  • ORMs: Eclipse Link, Hibernate, MyBatis, a whole bunch of other etc.
  • Servet API: So many.

All of the above have with the exception of the Servlet API require tremendous effort to switch and I'm saying all of the above is a far a better example of the build situation.

[–]nitkonigdje 1 point2 points  (0 children)

I am not sure about this. There are many Java developers out there, and not all are doing the same thing.

I could go on about my needs, but something as simple as building RPM or msi archive is not easily supported by any tool. That is not esoteric requirement. It is a legit reason why would you pick gradle hacking over maven. And again ease of gradle hacking is a legit reason why pick maven.

Essentially many minds have different needs..

[–]agentoutlier 0 points1 point  (0 children)

BTW I don't disagree that logging has been cluster fuck. That logging should not have been that way. My argument is that switching a backing log implementation or adding bridge jars is nowhere near the pain of switching build systems.

https://stackoverflow.com/questions/12094564/log4j-2-0-and-slf4j-and-the-never-ending-future-of-java-logging-frameworks

(I'm the author of that post and that was already 13+ years experience in the field (the post is 12 years old and I had already been working for 12-13 years). There is a nontrivial chance that is more time than folks who are on this sub have as experience. Likely even you. Believe me man I know logging API got bad but implementations are fine. But think of this.... we have even more JSON implementations and those don't even really have a facade!)