Review Request for 6879044
Alan.Bateman at Sun.COM
Mon Sep 14 09:17:07 UTC 2009
Mandy Chung wrote:
> 6879044: Eliminate the dependency of logging from the JRE
> core/awt/swing classes
The approach seems reasonable to me. It is a bit strange to redirect the
platform logging to j.u.logging if something up the stack starts logging
but I think we can live with this because these loggers are for
The changes to the AWT code are mostly mechanical, so I've only skimmed
these (assuming that someone from the AWT team with do a detailed check).
Have you tested this with a security manager set? I'm just wondering if
PlatformLogger's static initializer should do the property lookup in a
doPrivileged block. Also in the LoggerProxy for the line separator (BTW:
lineSeparator can be final).
Is isLoggingEnabled() used anywhere? I can't see it and wonder if it
should be removed. If it is used, then I assume it needs to be
synchronized with redirectPlatformLoggers.
You allow the PlatformLoggers to be GC'ed but the entries will remain in
the loggers map. I don't think this is a big deal because the AWT
classes will not be unloaded but might be worth putting a note in a
comment to re-visit this some time.
The static initializer in the forwarding proxy seems a bit messy. It
might look neater if changed to something like:
private static final Class<?> loggerClass =
private static final Method getLoggerMethod = getMethod(loggerClass,
where getClass does the Class.forName, returning null if CNF, getMethod
returns null if passed a null class, etc.
Minor nit but there are a few style/formatting issues in PlatformLogger.
For example, in JavaLogger there isn't a blank line between methods. It
might be worthing taking a pass over this to have it as neat as possible.
Do you have a bugID to track updating the http protocol handler? Jessie
did push some changes to eliminate the static dependency on logging and
it would be good if that code used PlatformLogger.
More information about the core-libs-dev