Re: Aspect questions?
On 02/26/2012 12:04 AM, markspace wrote:
On 2/25/2012 10:20 PM, Lew wrote:
markspace wrote:
(Different customers of yours prefer different loggers.)
That's what Apache Commons logging is for.
Back when I was playing with applets, I discovered by default that the jul
logger creates a log file in your home directory. (There's a default
logging.properties file created with every Java desktop installation and
that's what it does). With unsigned applets, this means even trying to
instantiate any part of the jul logging system will throw an exception,
because the applet has no permissions for creating files.
There might be ways around that, but it spooked me and I decided that since I
didn't have direct control over a user's system, I couldn't rely on any
defaults in the JRE installation. So I made a shell logging system that
wrapped the jul logger and allowed me control, in case I had to use something
besides jul entirely.
BTW, I wasn't aware that Apache Commons logging was different than JULI/log4j.
Thanks for pointing that out.
This requires that a logger is instantiated for each object as it is
created.
No, it doesn't.
It only creates one per class.
OK, assuming loggers are cached and reused, fair point.
It's not really a cache. The logger factory method is simply guaranteed to
return the same instance of the same-identified logger, just as say
'Integer.valueOf(5)' is guaranteed to return the same 'Integer' instance each
time within the program.
<http://docs.oracle.com/javase/7/docs/api/java/util/logging/Logger.html#getLogger(java.lang.String)>
"Find or create a logger for a named subsystem. If a logger has already been
created with the given name it is returned. Otherwise a new logger is created."
<http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Logger.html#getLogger(java.lang.String)>
"Retrieve a logger named according to the value of the name parameter. If the
named logger already exists, then the existing instance will be returned.
Otherwise, a new instance is created."
It's important to know what the system promises, and the Javadocs tell you.
The logging frameworks are foundational and should be part of the early
education of the Java programmer, along with the collections framework.
Knowledge of things like that all same-named loggers point to the same logger
instance is useful.
Lazy initialization is waaay overrated.
First prove you have an optimization problem before you present an
optimization solution.
Well, that "optimization" is code that my IDE writes by default. It costs me
nothing, so I'd rather prove that it's a problem before messing with it.
You mean the IDE generates lazy instantiation for you? It's a problem in that
it is additional code that resists best-practice idioms without benefit. The
fact that you have accepted someone else's default doesn't make it a great idea.
Your lazy acceptance of a lazy initialization idiom is not good for the code,
however much it may appear to you to save you the minute to change your IDE's
default to a saner approach.
I'm sensitive to habits, especially ones that lead to trouble. Maybe your
classes by default aren't meant for concurrent programs, for example, but I
never assume my classes won't be used that way. I also believe that if you
practice safe idioms you don't accidentally forget to use one when you need it.
Lazy instantiation has proven dangers and it causes things to be initialized
in an unpredictable way and out of the normal class sequence for eagerly
initialized items. Whether those dangers apply in this case or that case, it
costs nothing to do things the safe way and not have to shift gears when you
suspect danger.
If you really, really, really, really, really, really need to spawn a
thread to make logging faster, which you don't, you can do that over a
regular ju.logging or log4j call. You don't have to throw out the baby
with the bath water.
I've never had to spawn threads for logging, and the idea was something I've
only seen presented once, so I'm not sure how useful the concept is. However,
I keep it in mind as something that might have to happen someday.
It was the idea you suggested, though.
I was just responding with a way to follow your suggestion, with which I
disagree BTW, that didn't involve having to reinvent the whole logging
framework thing.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg