There is a lot of Cargo Cult programming going on among Java developers.
Why using a simple constructor when you can use the factory design pattern?
Or why directly instantiating a logger using the "new" statement and the right arguments, when you can also configure it using xml files? Making use of design patterns and frameworks is professional, after all, isn't?
Your statement sounds like a reverse cargo cult. The problem is not that people use these constructs that you mention. The problem is that people use the wrong constructs at the wrong time, don't seem particularly good at judging which to use when and just use the most convoluted one by default.
There are many contexts in which the factory pattern is the best choice (although not the majority) and in which configuring logging externally is the best choice (almost always).
Actually, configuring logger with values stored in a separate file instead of hardcoded ones is a good thing. Logging configuration is configuration, after all.
You wouldn't want paths to documents be hardcoded in your office suite, would you? Or target address of VPN gateway in VPN client?
Hard coded logger instantiation in a library is anti-pattern. Whoever is using your library usually has his own opinions on how much of your stuff he wants in logs.
Why are you assuming that he is writing a library? I have seen people bloat up simple java applications with provision for future requirements which will never happen in the real world.
Logging is still weird example to pick up for it. First, it make sense to have it configurable in production (and yes we ask clients to raise logging level in production we have no access to in case of troubleshooting).
Second, it is not like each java program would be inventing its own super complicated xml like logging configuration. It is pretty much always done the same standard way. Pretty much every java app uses one of two standard logging libraries and those libraries share the same API.
You can configure that standard API in xml, through properties file or in code and all three methods are basically the same thing in three different syntaxes. None of them is easier or harder then the other two and everyone is familiar with both xml and properties file one.
No one normally obsess about logging code too much. It is the least obtrusive easiest to do part of anything you can possibly work at.
Sorry the logging thing and the configuration thing wasn't my point. What I was trying to say was all the best practices and standard way of doing things are not set in stone and should be evaluated at every instance. Beginners write very inflexible code. When intermediate, they learn best practices and about making it flexible and keeping room for the future. But only after seeing enough projects in production, one will know which flexibilities make sense to the project at hand and which don't.
For example, some changes even though very easy to implement are very difficult to push in production because of requirement of senior management approvals.
Also, best practices depend on the actual environment that you work on. For e.g. In one of the projects, the DBA team had very cool people compared to the server admins who were a pain to deal with even when we had all the approvals. So we decided to keep the configurations in a table and not xml, as changes could be pushed easily!
Over the years I've developed a deep understanding for why XML configuration is great. Java's move to annotation, upon annotation. As a result there is no single, canonical place I can go to see what the general configuration is. I have to track through classes, that may or may not have a good structure to find a specific instance of a route. Spring 3.x configurations, with inheritance are wonderful. The only work is to follow the imports.
Why using a simple constructor when you can use the factory design pattern? Or why directly instantiating a logger using the "new" statement and the right arguments, when you can also configure it using xml files? Making use of design patterns and frameworks is professional, after all, isn't?