RFR: 8139982 Re-examine java.management dependency on java.util.logging.LoggingMXBean

[Mandy Chung]

Hi Daniel,

> On Apr 29, 2016, at 8:08 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a patch [2] that eliminates a static
> dependency of java.lang.management on java.util.logging.LoggingMXBean.
> 
> When JDK-6876135 was fixed, it introduced the PlatformLoggingMXBean
> interface, and recommended using PlatformLoggingMXBean over
> LoggingMXBean.

Adding to this, JDK-6876135 prepared the JDK for modularization and PlatformLoggingMXBean was introduced that can be replaced with existing usage of LoggingMXBean.

With this change, java.management dependency on java.logging will become implementation details for logging purpose and can be eliminated completely in the future.

About the deprecation, to be specific, LoggingMXBean will no longer be a platform MXBean and an instance of LoggingMXBean will not register in the platform MBeanServer.

This is a revised wording for the deprecation note for LoggingMXBean:

@deprecated {@code LoggingMXBean} is no longer a {@link java.lang.management.PlatformManagedObject platform MXBean} and replaced with {@link java.lang.management.PlatformLoggingMXBean}.
It will not register in the platform MBeanServer. Use 
{@code ManagementFactory.getPlatformMXBean(PlatformLoggingMXBean.class)} instead.

One question about: ManagementFactory::getPlatformMXBean(MBeanServerConnection, PlatformLoggingMXBean.class)
- what would happen if this method is called from an image with java.logging module present and connect to a VM with no java.logging module?  Should the ManagementFactory::getPlatformMXBean spec or PlatformLoggingMXBean spec be clarified?

ManagementFactoryHelper.java

 191                 if (result != null) {
 192                     LoggingMXBeanSupport.class.getModule().addReads(m);
 193                 }

Reflection access assumes readability now:
  http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectionWithoutReadability

So this addReads is not needed.

 252         final Map<String, Method> methods = AccessController.doPrivileged(
 253             new PrivilegedAction<>() {
 254                 @Override
 255                 public Map<String, Method> run() {
 256                     return initMethodMap(impl);
 257                 }
 258             });

I believe this doPrivileged is not necessary and so do the other getMethod calls.  Probably you are thinking ahead what if java.management may one day be defined by a child loader of the defining loader of java.logging.  Then you can move doPrivileged to initMethodMap.

 217                     // skip
- better to throw InternalError since it expects all methods are used?

 273                 throw new SecurityException(ex);
- should not reach here.  SecurityException may cause confusion since this will be thrown even without security manager.  could simply throw InternalException

 296         private PlatformLoggingImpl(LoggingMXBeanSupport support) {
- perhaps renaming LoggingMXBeanSupport to LoggingProxy to better represent it.

> 
> Backward Compatibility considerations:
> --------------------------------------
> 
> 1. Local clients which obtain an instance of the logging
> MXBean by calling ManagementFactory.getPlatformMXBean(
>            "java.util.logging:type=Logging",
>             PlatformLoggingMXBean.class)
> will no longer be able to cast the result on
> java.util.logging.LoggingMXBean.
> [There should be few, given that PlatformLoggingMXBean
>  already has all the methods defined in LoggingMXBean]
> 

I expect this would be really rare too.

> 2. ManagementFactory.getPlatformMBeanServer().isInstanceOf(
>     ObjectName, "java.util.logging.LoggingMXBean")
> will now return 'false' instead of 'true'.
> 
> 3. The Logging MXBean MBeanInfo will now report that its
> management interface is "java.lang.management.PlatformLoggingMXBean"
> instead of "sun.management.ManagementFactoryHelper$LoggingMXBean”.

Any impact to permission confiugred in security policy? Should also document that.

> 4. Calls to ManagementFactory.newPlatformMXBeanProxy(
>    MBeanServerConnection, ObjectName,
>    java.util.logging.LoggingMXBean.class); and
> JMX.newMXBeanProxy(MBeanServerConnection, ObjectName,
>    java.util.logging.LoggingMXBean.class)
> will continue to work as before.
> 

> 5. Remote clients running previous version of the JDK
>    should see no changes, except for the interface
>    name in MBeanInfo, and the change in isInstanceOf
>    reported in 2.

This is good.

The incompatibility risk for this change is rather low.

Mandy