HI Mandy,
On Sat, Sep 19, 2009 at 12:19 AM, Mandy Chung <mandy.ch...@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) [1], 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
application
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:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-July/000181.html
http://cr.openjdk.java.net/~mchung/startup_measurement/perfdata.summary.b64
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
well-justified.
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
anyway.
Oleg.
If you have further issue, I suggest to start a different thread on the
awt-dev alias.
Thanks
Mandy
[1] http://jcp.org/aboutJava/communityprocess/first/jsr047/index.html
