[OpenJDK 2D-Dev] <AWT Dev> Review Request for 6879044

[Mandy Chung]

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
>