Hi Daniel,
> On Oct 9, 2015, at 12:53 PM, Daniel Fuchs <[email protected]> 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
