Oleg Sukhodolsky wrote:
On Mon, Sep 14, 2009 at 9:19 PM, Mandy Chung <mandy.ch...@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
