<AWT Dev> Review Request for 6879044

[Mandy Chung]

Oleg Sukhodolsky wrote:
> On Mon, Sep 14, 2009 at 9:19 PM, Mandy Chung <Mandy.Chung at sun.com> wrote:
> 
> I thought that it is possible to log int a file using default logger,

Not the default logging configuration.

> 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.

System.err is the default configuration that ConsoleHandler will output 
to.  The default handler specified in <JRE>/lib/logging.properties is:

# By default we only configure a ConsoleHandler, which will only
# show messages at the INFO and above levels.
handlers= java.util.logging.ConsoleHandler

# To also add the FileHandler, use the following line instead.
#handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler

If you want to log to a file, you need to supply a logging.properties to 
alter the handles property.   If you specify 
-Djava.util.logging.config.file=<your logging.properties>, all log 
messages will go to the file as described by your logging.properties. 
The only difference with the fix is that the platform loggers doesn't 
check if the <JRE>/lib/logging.properties is modified.

> internal PlatformLogger is present in Sun's implementation of JRE
> only, so such changes will
> complicate porting JRE implementation.  

How does it complicate the porting?

The issue we are dealing with is that the JDK is big and deeply 
interconnected [1].  A command-line hello program loads 300 classes and 
a Framer (awt version of helloworld) loads 834 classes running with JDK 
7 b71.

Without module support  (JSR 294 + jigsaw) - like we are today, 
continual JDK development could cause startup of a simple awt app to 
load over 1000 classes very easily (I actually recalled that one point 
in time it was over 1000 classes but we put a fix to reduce the number 
of loaded classes).

> 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?

Not only the MB of the java.util.logging classes but the classes they 
pull in at runtime.

> I'd suggest to keep all logger's initialization as is to simplify the fix.

My goal is to reduce the number of logger instances created at startup. 
  In addition, I think the fix is very simple.  As I mentioned in my 
reply to Andrew, Alex Potochkin also brought up a consistency issue that 
will be addressed by 6880089 or a new CR.

I'm ok to take out the lazy initialization of AWT loggers in my fix as 
long as the AWT team is going to fix 6880089 soon.  Artem, Alex, what do 
you think?

Thanks
Mandy

[1] http://blogs.sun.com/mr/entry/massive_monolithic_jdk