Hi Mandy,
As we discussed I have also made LogManager.demandLoggerFor
package protected. As a result I also reverted the changes
to LoggingPermission - there's no reason for exposing
a LoggingPermission("demandLogger", null) if LogManager.demandLoggerFor
is no longer visible.I have refreshed the content of the links & the sandbox. specdiff:http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html
webrev: http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html sandbox: JDK-8046565-branch best regards, -- daniel On 19/10/15 20:18, Daniel Fuchs wrote:
Hi Mandy, I have updated the links with the modifications we discussed last Friday: - I have removed the tag @apiNote from System.LoggerFinder - I have relaxed the constraint of what happens if several implementations of LoggerFinder are present - the specification no longer mandate that ServiceConfigurationError is thrown, and the implementation will simply take the first one returned by the ServiceLoader. - I have moved PlatformLoggerBridge and ConfigurableLoggerBridge to be inner interfaces of PlatformLogger: PlatformLoggerBridge => PlatformLogger.Bridge ConfigurableLoggerBridge => PlatformLogger.ConfigurableBridge (and fixed their class-level javadoc as well) I have pushed the changes to the sandbox (JDK-8046565-branch) and updated the content of 'proto.02' (same link as before: specdiff: http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html webrev: http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html best regards, -- daniel On 14/10/15 22:57, Mandy Chung wrote:Addiitional comments: JdkLoggerProvider.java - should the GC’ed referent entries in the application SharedLoggers map be occasionally drained? BootstrapLogger.java In the BootstrapExecutors::join(Runnable r) method: try { getExecutor().submit(r).get(); } catch (InterruptedException | ExecutionException ex) { // should not happen ex.printStackTrace(System.err); } - we should avoid output any debugging code though. typos: indepedent temporarilly // Unfortunately, if we come to here it means we are in the bootsraping // phase where using lambdas is not safe yet - so we have to use a // a data object instead… FYI. jake has changed the system initialization sequence that allows the use of lambda early at startup. That may help in this case that you can revisit this in the future. This reminds me the startup performance. Is there any use System.Logger to log message during startup in JDK 9? Using lambda at startup will have impact to the startup performance. Also I’m curious to know the difference of classes loaded at startup if System.getLogger is called in one of the system class loaded during startup but no log message is output (as typical case is to print debugging message) with and without java.logging. // Not sure whether this is needed: it was in the original // PlatformLogger proxy code: - I don’t understand why sun.util.logger.LazyLoggers$JdkLazyLogger need to be loaded. DetectBackend is loaded only after booted (per the comment) Naming nit: PlatformLoggerBridge - would it be better to move to PlatformLogger.Bridge? It’s nit and I think it reads better and clearly associate with PlatformLogger. Mandy
