harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zakharov, Vasily M" <vasily.m.zakha...@intel.com>
Subject RE: [classlib] logging from within our implementation
Date Tue, 30 May 2006 22:16:06 GMT

"At the end we are going to dump any logging debris that have any 
performance or other burden like increase in dependencies"

It's Open Source. There's no "end". The bugs will continue to get found,
and new features and optimizations will appear from time to time.
And putting them in would require checking and debugging, and good
logging
will help at these stages too.

j.u.l logging is well designed, and if used correctly, has minimal
performance
penalty, since unused logging directives are simply wiped out by
optmimizing Jit.

 Vasily


-----Original Message-----
From: Geir Magnusson Jr [mailto:geir@pobox.com] 
Sent: Tuesday, May 30, 2006 10:59 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] logging from within our implementation

Just to be clear, I certainly sympathize with Tim and support getting 
rid of implementation debug logging in the long term.

Maybe the way to compromise/phrase it is agree that when a package is 
done, we will pitch all the logging?  I can see why having logging 
around while things are being developed is helpful, and committing to 
SVN is ok since we want people to commit "early and often, and having to

pull out logging would be a disincentive for someone working on 
something big.

Does this help?

"At the end we are going to dump any logging debris that have any 
performance or other burden like increase in dependencies"

geir


Geir Magnusson Jr wrote:
> 
> 
> Tim Ellison wrote:
>> Geir Magnusson Jr wrote:
>>> Seems like there is an important issue here, but the discussion
can't
>>> seem to escape out of the thicket of the example.
>>>
>>> 1) Should we allow any logging from within the classlibrary?
>>
>> Just in case there was any doubt from my earlier postings...
>>
>> I think we should not be explicitly logging debug info as part of our
>> class library implementation.
> 
> In any form?
> 
>>> 2) How should we do it?
>>>
>>> There are a bunch of ways for the second question...  using j.u.l,
using
>>>  IOC and injecting our own logging target to reduce dependencies and
>>> make people think before logging, using aspects?
>>
>> Both j.u.l and IoC would require code in the implementation to
perform
>> the logging actions (or check the guard).  Putting this logic
throughout
>> the class library will IMHO result in module coupling, code bloat and
>> overall performance degradation (or no logging!).
> 
> Right - that's why I was thinking of the latter.  Something that would

> have no runtime overhead, yet allow us to capture more information
other 
> than just execution path and stack values :)
>>
>> Adding logging statements is expecting the class library developer to
>> decide /a priori/ what debug|trace info is useful to the person
trying
>> to resolve a problem.  Existing debug|trace tools work with the
runtime
>> to figure out the pertinent information as you are interested in it.
>> (The only caveat being 'flight data recorder' type trace where the
trace
>> points are typically very low overhead and always on).
>>
>>> Comments?  We probably should try to get to a conclusion in
general...
>>
>> The logging info being proposed is developer-oriented.  I hope that
>> people are not expecting our users to understand our developer trace
>> info -- we, as developers, have better tools than printf to figure
out
>> what is happening.
> 
> I have to admit that I don't agree w/ "better" as a universally
general 
> statement, as debug statements can include information provided by the

> developer not immediately obvious.
> 
> Is there some kind of aspect framework we can use?  Then for 
> develeopers, they have to implicitly do something to get the stuff to 
> come out, it's not a runtime cost for anyone else, and the stuff stays

> in the codebase for use later?
> 
> geir
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message