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
