There is no change to the log messages emitted from awt/2d/swing. The
only impact to the end users is if they enable logging by modifying the
system-wide logging.properties (see below); otherwise, the end users
will not notice any change due to this fix.
The following are the common ways to enable logging:
1) set -Djava.util.logging.config.file=<your own logging.properties>
system properties in the command-line
This fix has no impact to the end user. Typically for debugging
purpose, a user will have their custom logging.properties instead of
modify the system-wide logging.properties as they would impact all Java
apps.
2) Modify the system-wide logging.properties in the JRE local copy (
<JRE>/lib/logging.properties)
This fix has impact to the end user and they will need to add
-Djava.util.logging.config.file=<JRE>/lib/logging.properties option in
the command-line.
3) Have their own java.util.logging.config.class implementation
This fix has no impact to the end user.
Thanks
Mandy
Igor Nekrestyanov wrote:
We have discussed this with Anthony and Andrei offline and they do not
seem to have any blocking concerns.
There is one suggestion though - there should be simple explanation
for "are there any changes required on the end user side
to enable logging and if so, what are they". Logging is mostly used to
get details from remote user and ideally
instructions that were sent to such users (i.e. "if you have
focus-related issue please do this and send us this") should not change
(or it should be explained how they are changing).
Anthony/Andrei, please speak up if you have other concerns.
-igor
On 9/23/09 5:08 AM, Anthony Petrov wrote:
On 09/23/2009 03:41 PM, Alan Bateman wrote:
If AWT initialized the loggers lazily, and only did it when the
logging is actually enabled (checking for some system property, or
whatever other way), would we still be statically linked to the
j.u.logging package in case of a regular client application that
does not use/enable logging explicitly?
Yes, minimally they should be created lazily (this is one of the
suggestions that Mandy listed in 6880089). That would at least avoid
initializing all these loggers. The static dependency remains.
Ah, I just looked over the PlatformLogger code, and now I see it uses
reflection to access the j.u.logging.* classes. Now this point is clear.
Have it been discussed whether that is feasible to modify the VM in
order to eliminate the static dependency if a particular object never
gets initialized?
It just looks kind of artificial to create such proxy classes. I bet
we'll need plenty of them for other modules. Won't the code be messed
up too much?
--
best regards,
Anthony
