[OpenJDK 2D-Dev] <AWT Dev> Review Request for 6879044

[Oleg Sukhodolsky]

On Tue, Sep 15, 2009 at 11:13 PM, Mandy Chung <Mandy.Chung at sun.com> wrote:
>
>
> 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?

I'm not sure that IBM's or some other's version of JDK is allowed to
contain such
classes, thus it may be harder to port our RI to their implementation .

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

What if an application will use logging? How many Logger.getLogger()
user need to add to his(her)
code to completely initialize logging and make your changes useless?  How often
we will have user's code which doesn't use logging?
Why we have to remove all usages of logging in our code instead of
changing logging package to be
more startup friendly?

Oleg.

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