On Thu, Sep 17, 2009 at 2:43 PM, Alan Bateman <alan.bate...@sun.com> wrote: > Anthony Petrov wrote: >> >> : >> I have to say that that is not the best possible solution. For instance, >> the sun.awt.X11 classes have many different loggers: for focus-related code, >> for insets-related code, and so on. If a developer debugs a particular kind >> of problem, (s)he doesn't need to look through all the garbage that other >> loggers generate: it's just enough to enable a particular logging facility >> (such as the >> "sun.awt.X11.insets.XDecoratedPeer" for example) and examine what (s)he >> really needs. >> Combining all the output to just one logger will make debugging a >> nightmare. >> >> I would second to Oleg: improving the performance/design of the existing >> logging classes at java.util.logging package would help all applications at >> once. > > I'm not familiar with the AWT implementation to have a strong view as to how > 6880089 is addressed. However, Mandy does raise a good question as to why > there is a need for so many loggers. I think one mail mentioned there 85 > loggers setup when running simple "hello world" Framer test. Maybe they can > be created lazily; maybe some of them aren't needed, but at least there is a > bug created so that someone can re-visit this. I agree that any improvements > to j.u.logging would be welcome too but that doesn't solve the desire to > decouple the dependency.
imho removing dependency on j.u.logging for me looks as strange as removing dependency on j.l.Object or java.util.* :) > For example, if the libraries are broken up into a > set of fine grain modules then why would I need to have a logging module > installed to run a simple client application? Perhaps because most application use logging ;)