<AWT Dev> [OpenJDK 2D-Dev] Review Request for 6879044
Andrei.Dmitriev at Sun.COM
Mon Sep 21 08:49:17 UTC 2009
Hi Mandy, Oleg,
I'm going to summarize pros and cons of this change just to make judge
(basically for myself).
1) we can't expect a significant memory gain (the numbers are ~90Kb).
That's a minus.
2) we decouple awt/swing/2d with logging package which is a Plus in a
view of jigsaw. See 6) for more.
3) we don't have time measures for this change. That's a minus.
4) nobody measured anything else than Framer and SwingSet. That's a minus.
5) we lose flexibility on debugging. That's a minus.
6) this fix don't decouple anything else awt/swing/2d.
I made a grep on "Logger.getLogger" and there are entries from xml, jmx,
etc. That means we have to deal with them as well too (as it causes the
class to be loaded anyway), if we aware of jigsaw.
7) In most cases AWT initiates classes statically but basically may want
to do that lazily. That's minus. I'd consider initialization in CTOR at
first and see the impact. Believe SwingSet would show enough here. If
not, that's the reason to go further to... well to check if the Java
Now, I don't see the evaluation is completed to make the decision. And
if we could modify client code in the way that Framer will never
initialize or/and load Logger (et al) classes so we achieved the goal.
Oleg Sukhodolsky wrote:
> HI Mandy,
> On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung <Mandy.Chung at sun.com> wrote:
>> Hi Oleg,
>> A better question to ask is who and how the logging information AWT is used
>> for. The AWT team confirms that the AWT loggers are for debugging purpose
>> used by the awt developers. As specified in the Requirements chapter for
>> the Java Logging Spec (JSR-47) , the central goal of the logging API is
>> to support maintaining and servicing software at customer sites. Adding
>> debugging code in the awt implementation using logging API is reasonable but
>> it's not the requirement for the logging API. If there were a better option
>> to add debugging code, I believe you have no problem changing the awt
>> debugging code not to use the logging API.
>> Server-type applications are typical use cases that logging information is
>> very important and useful for diagnosis in the field - long running apps,
>> hard to reproduce problems until running for many days/months. It is hard
>> to imagine how the logging information is important in client applications.
> as ex-AWT developer I can confirm that there were number of cases when
> logging had helped us to diagnose problem on client's site. Even
> though you usually
> do not need to run an application for a long time to reproduce a problem
> it can be very hard to reproduce it because the problem depends on
> window manager
> and other environment which is hard to re-create.
>> But you seem to know many client applications use the logging API that I
>> would also be interested to follow up with their requirements.
> I do not know many client applications which uses logging API (because I have
> never write real client application) and it is hard to say if it uses
> logging or not.
> I hoped that you who saying that suggested changes will help to client
> has some statistic to confirm your expectation
>>> Ok, so this fix is only about modules. But why AWT should not depend
>>> on logging module?
>>> The qiestion is: how many application we want to run doesn't use
>>> logging& Because if an application
>>> uses logging there is no reasons for AWT to not use it. Please note
>>> that even if logging is turned
>>> off, the application still needs logging package/module. So, though
>>> end-user doesn't need logging output
>>> she may need logging module to run the application.
>> This is exactly why we want to decouple the dependency on logging. When an
>> application uses logging, the application knows clearly what module they
>> require and that's fine. When an application doesn't logging, if the awt
>> component requires logging for debugging purpose only, it increases the
>> download size, footprint and startup performance (class lookup time,
>> loading, init, etc) - please see my performance analysis report; otherwise,
>> it's not fruitful to discuss the details in this thread without the
>> background info. Just to mention it what we care about.
> I have found only two links to some performance analysis:
> but they say about -Xverify and -Xshare and do not understand how they
> can be related
> to our topic :( If they do, please explain (I have never been an
> expert in this area :(
> Or, if I missed something could you please point me what I have missed.
>>> So, it is really
>>> important to understand
>>> what number of application will get advantage of suggested changes.
>> You are suggesting the client applications always have a dependency on
>> logging. Many client team engineers are happy to see the dependency on
>> logging being eliminated from the client stack requirement and approve this
>> fix :)
> I do not see how this can be considered as prove that the changes will
> help client applications.
> Unless we have some statistic it is all just our guess (which, as we
> know, usually wrong ;)
>>> Second question is: how big logging module is going to be? How big the
>>> benefit for end-user will be?
>> The size of the logging API is not big (~90K) but the size is not the only
>> one factor determining what benefit the end-user will have.
> what other factors do you know?
>> It's not
>> necessary to logging API as one single module and details are to be worked
>> out. Subscribe to the jigsaw project to follow the discussion and progress
>> there. Serviceability includes other API as well. If awt started using
>> other serviceability API (java.lang.management, java.lang.instrument) for
>> whatever reason, your argument would apply there as well. I don't think you
>> wanted the awt module depends on all the serviceability APIs.
> I agree that usage of any API should be done after careful consideration.
> Logging API provides us exactly what we need (ability to create log of
> an application
> executed on client) this is why we started to use it.
>>> I'm asking so many question mainly because the changes you suggested
>>> create rather unnatural code (we can not
>>> use standard logging machinery any more), so such changes should be
>> That's what we pay for to modularize the JDK after many years of JDK
>> development without module support in the platform. Otherwise, if there
>> were module support in the platform, you would consider very carefully when
>> adding a dependency on another module.
> perhaps you are right, but in case of logging I would expect that we'd use it
>> If you have further issue, I suggest to start a different thread on the
>> awt-dev alias.
>>  http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
More information about the core-libs-dev