RFR: JDK-8046565: Platform Logger API and Service

Daniel Fuchs daniel.fuchs at oracle.com
Tue Oct 20 21:48:39 UTC 2015


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




More information about the core-libs-dev mailing list