3 ms·
I use java.util.logging in a few apps, to cut down on dependencies, and i consider it to be fairly braindead. The fundamentals are okay, to the extent that they
by twic 4y ago
I use java.util.logging in a few apps, to cut down on dependencies, and i consider it to be fairly braindead. The fundamentals are okay, to the extent that they are copies of log4j, but there are a bunch of little things that just aren't done right, like:
- logging methods taking arrays rather than varargs (this would be a trivial change!)
- there being no way to create a SimpleFormatter with a custom format in code other than setting a system property before creating it
- there being no Logger:getLogger override which takes a class, only strings
At some point, i am going to write a little facade which wraps jul and fixes the papercuts, which feels like a very silly thing to be doing!
- layer8 4y agoThose are cosmetic issues, in my book. The basic architecture is sound. In any serious application you will want to have a central logging wrapper anyway (I always use one), which automatically takes care of the varargs issue. The implementation of SimpleFormatter is 30 lines that you can easily copy and adjust as needed, including with your own custom format. Regarding logger names, I always define an explicit set of logger names for the application, because that makes the logger names independent from implementation-detail subpackages, and any operations-side log filtering based on logger names will remains stable, regardless of how you refactor your implementation into Java packages. Basically, I see the logger names as part of the external interface of the application, and therefore I want to have them decoupled from the internal package structure, so that mere refactorings don't break that interface. You can still easily find all program locations that log to a specific logger, for example by Find Usages on the respective static Logger constant.
- EdwardDiego 4y ago- the console appender writes to stderr.