RFR: JDK-8046565: Platform Logger API and Service

Daniel Fuchs daniel.fuchs at oracle.com
Fri Oct 16 10:44:22 UTC 2015

Hi Mandy,

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?

Right. Will do.

> 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.

OK. This is only used in unit tests. I will rethrow a
RuntimeException instead.

> 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.

Depends on the definition of 'startup'. java.desktop can be
very verbose when you enable its loggers.

> 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.

Yes, that would be interesting.

> // 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)

OK - will remove this.

> 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.

That could be a good idea.

-- daniel

> Mandy

More information about the core-libs-dev mailing list