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. But you seem to know many client applications use the
logging API that I would also be interested to follow up with their
requirements.
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.
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 :)
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. 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'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.
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
