<AWT Dev> Review Request for 6879044

Oleg Sukhodolsky son.two at gmail.com
Mon Sep 14 20:04:10 PDT 2009

On Mon, Sep 14, 2009 at 9:19 PM, Mandy Chung <Mandy.Chung at sun.com> wrote:
> Oleg Sukhodolsky wrote:
>> On Mon, Sep 14, 2009 at 5:32 AM, Mandy Chung <Mandy.Chung at 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.


> 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

More information about the awt-dev mailing list