On Mon, Sep 14, 2009 at 9:19 PM, Mandy Chung <mandy.ch...@sun.com> wrote: > Oleg Sukhodolsky wrote: >> >> On Mon, Sep 14, 2009 at 5:32 AM, Mandy Chung <mandy.ch...@sun.com> wrote: >>> >>> 6879044: Eliminate the dependency of logging from the JRE core/awt/swing >>> classes >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/6879044/webrev.00/ >>> >>> Summary: >>> 1. A new sun.util.logging.PlatformLogger class that will handle the log >>> messages in a similar way as Logger but it will only delegate to >>> java.util.logging only when it is enabled. LogManager and LogRecord are >>> modified to support the platform loggers. The users of PlatformLogger >>> will >>> continue to run if java.util.logging classes do not exist. >> >> evaluation for 6879044 says: >> >> Add a PlatformLogger class that mimics the default logging behavior >> (output the log message to System.err with simple formatting) and >> creates a java.util.logging.Logger only when the logging facility is >> used by the application or a user-defined configuration is supplied. >> >> which of two descriptions is correct one? > > Both are correct. Can you elaborate what issue;/confusion you see between > the descriptions?
I thought that it is possible to log int a file using default logger, thus I was surprised that description of PlatformLogger says about System.err. I'd expect PlatformLogger to be a wrapper around the default logger, and as far as I can see from provided sources it is. > The class description of sun.util.logging.PlatformLogger has the details: > http://cr.openjdk.java.net/~mchung/6879044/webrev.00/src/share/classes/sun/util/logging/PlatformLogger.java.html > >> Also I wonder if it is ok to get possible better modularization by >> adding dependency to Sun's internal API into public packages. > > This fix is to eliminate the dependency to logging API. This internal > PlatformLogger class is an implementation class only used by the JRE and > always be present. Does this answer your question? internal PlatformLogger is present in Sun's implementation of JRE only, so such changes will complicate porting JRE implementation. Also I wonder how big logging module is, what advantage we do receive by removing dependency on it? How many Mb we do not need to load in this case? >>> 2. AWT, 2D, Swing, and a few java.util classes are modified to use >>> PlatformLogger instead of Logger. Although many files are modified, the >>> change is mostly replacement with classname. >> >> Well, at least in AWTEvent you have changed static initialization of >> logger to lazy one. >> Perhaps it is better to keep a static one to minimize your changes. > > This fix shows one way of lazy initializing an AWT logger to be referenced > when fixing 6880089. The AWTEvent log messages are only output in the error > conditions. In the normal cases, no message will be logged in this logger > is not needed. I would expect that the fix for 6880089 may make some AWT > loggers to be initialized lazily as this one. I'd suggest to keep all logger's initialization as is to simplify the fix. Oleg. > > Thanks for the review. > Mandy > >> Oleg. >>> >>> AWT statically creates a number of loggers. Running a simple AWT Framer >>> application with JDK 7 b71 creates 79 loggers on solaris-i586 and 34 >>> loggers >>> on windows-i586. SwingSet2 creates a total of 85 loggers including a few >>> non-awt ones on solaris-i586 and 35 on windows-i586). >>> Although the memory usage might not be very high (especially with this >>> fix), >>> I don't see the need of having many fine-grained loggers. This fix >>> doesn't >>> address this the number of AWT loggers. I file a separate CR (6880089) to >>> revisit it. >>> >>> Startup Performance: >>> This change does not have significant startup performance improvement, as >>> expected. However, it does reduce the number of loaded classes (Framer >>> app >>> loads 16 fewer classes and jedit loads 13 fewer classes). >>> >>> >>> Thanks >>> Mandy >>> >>> >>> >