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
