RFR: JDK-8046565: Platform Logging API and Service

[Mandy Chung]

Hi Daniel,

> On Oct 9, 2015, at 12:53 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> JEP:
> http://openjdk.java.net/jeps/264
> https://bugs.openjdk.java.net/browse/JDK-8046565
> 
> specdiff:
> http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/webrev.01/


This is very good work.  I’m glad to see this work that enables the dependency on java.logging be eliminated.  The sun.util.logging.PlatformLogger was a stop-gap approach.

There are many new tests that I will need time to review them all.  I’m going to pass you my comments in several batches.  This is the first batch.

LogManager.java
1938         if (caller.getClassLoader() == null) {
1939             return LogManager.getLogManager().demandSystemLogger(name,
1940                 Logger.SYSTEM_LOGGER_RB_NAME, caller);

This only considers the classes loaded by the boot loader as system classes.  We have deprivileged several modules to be loaded by the ext class loader such as JAX-WS, JAXB, CORBA etc.  Loggers created by modules loaded by boot and ext class loader should be system.

In the absence of java.logging, the default provider implementation will be used to print the log messages to System.err.  This is useful since most JDK log messages are for debugging.  I expect that a component may want to turn on debug messages without requiring the presence of java.logging.

Is there any mechanism to change the default level of the default simple console loggers?  It may be useful; otherwise it would need  to run on an image with java.logging module.  Maybe something to add in the future.

System.Logger
964      * Unless
- incomplete sentence?

1697      * @implSpec
1698      * Instances returned by this method route messages to loggers
1699      * obtained by calling {@link LoggerFinder#getLogger(java.lang.String, java.lang.Class)
1700      * LoggerFinder.getLogger(name, ca

Is this intended to be implementation specification but not API spec?  

RuntimePermission(“LoggerFinder) is required in the provider constructor.
- is it time to define a ServiceProviderPermission for provider constructor security permission check?  Rather than overloading RuntimePermission

public static final RuntimePermission LOGGERFINDER_PERMISSION =
         new RuntimePermission("loggerFinder”);
- is there any need to define this constant?  Suggest this be implementation-details.

private LoggerFinderLoader() {
     throw new InternalError("LoggerFinderLoader cannot be instantiated");
}
- is throwing InternalError necessary?  No one else except its enclosing class can construct it.

JdkLoggingProvider::LOGGING_CONTROL_PERMISSION
- I think this field is unused.

sun/management/ManagementFactoryHelper.java
- Is LoggingMXBeanSupport intended to get  java.management to remove its dependency on java.logging?

  172     public interface LoggingMXBean
  173         extends PlatformLoggingMXBean, java.util.logging.LoggingMXBean {
  174     }

This static dependency will still keep the dependency on java.logging.

Mandy