Change Log for JSR 3 Maintenance Review 4
Éamonn McManus, JSR 3 Maintenance Lead
This is the Change Log for the fourth Maintenance Review of JSR
3. Questions and comments on this Change Log should be directed
This Maintenance Review defines version 1.4 of the JMX API
as originally defined by JSR 3.
The 7-digit code numbers associated with each change are
identifiers in the public bug database at bugs.sun.com.
A larger set of updates to the JMX specification is planned as
part of JSR 255, "JMX Specification, version 2.0". The changes
proposed in this Maintenance Review are intended as interim
steps towards JSR 255. These changes have all been approved by
the JSR 255 Expert Group.
An updated standalone TCK will be available that reflects the
changes in this Maintenance Review. In addition, it is intended
that these changes will be included in the Java SE 6 ("Mustang")
This class is unusable by code outside the package it is defined
in, because its only visible constructor has a parameter whose
type is a non-public class. If you call that constructor with a
null parameter, you get an immediate exception. Therefore,
exceptionally, this public class can safely be deleted from the
Java SE API.
Better support for schema evolution in
CompositeData and CompositeType (5072004)
Given a CompositeType
ct, the method javax.management.openmbean.CompositeType.isValue(x)
previously returned true only if x was a CompositeData
was equal to ct. This rule has been relaxed. The type returned
by x.getCompositeType() must still have the same name as ct, and
it must have all the same items as ct, but it can have additional
items. This change also impacts the rules for TabularType.isValue
regarding CompositeData items contained by the TabularData or the
OpenType should not declare public static array
This field is deprecated in favour of a new field
CompositeDataView.toCompositeData should have
CompositeType parameter (6392303)
The signature of this method has changed from toCompositeData() to
toCompositeData(CompositeType ct) to simplify typical uses.
DescriptorKey has inconsistent meta-annotations
The definition of the @DescriptorKey
annotation had a spurious @Inherited
meta-annotation which has been removed.
ModelMBeanConstructorInfo says certain fields
invalid, but doesn't check (6236765)
The specification of ModelMBeanConstructorInfo
previously said that the persistPolicy and currencyTimeLimit
fields were invalid, but the Reference Implementation did not
check this. To avoid breaking existing code that might have
included those fields, the specification has been changed to say
that they are meaningless but are not considered invalid.
MLet support for native libraries is
underspecified and should be optional (6223396)
The specification of MLet.findLibrary
has been updated to detail the algorithm used to find native
libraries inside jar files, and to add a @throws clause for
implementations that do not support this functionality. The PDF
specification has been updated similarly (section 8.3.2).
Clarify how DescriptorKey used in an MBean
interface is handled (6355323)
The specification is updated to say that annotations defined with
are only considered on the most specific occurrence of a method in
the interface hierarchy.
Clarify behaviour when null Descriptor parameter
to MBeanInfo etc (6289244)
The specification of the constructors of MBeanInfo
and related classes previously stated that a null input value for the
Descriptor parameter would produce an empty Descriptor. In fact
it is equivalent to an empty Descriptor input value, to which the
implementation can add certain standard fields.
Better specify type strings in MXBean descriptors
The specification of type strings in the originalType field of an
MXBean descriptor has been clarified
in the MXBean specification.
Added conventional metricType Descriptor field
A field metricType has been added to the list of conventional Descriptor
fields to specify whether a value is a counter or a gauge.
Specify that // is reserved in ObjectName domains
It is planned to use the string // in ObjectName
domains as part of the "cascading" feature in the next version of
the JMX API. A warning has been added to the specification that
this string should be avoided, even though the string does not yet
have any special meaning to the implementation.
JMX implementations should be allowed to make
permission checks even if no SecurityManager (6419572)
The JMX specification previously said that permissions checks were
made if and only if there is a non-null SecurityManager.
This has been changed to say that an implementation is free not to
make checks if there is no SecurityManager. In other words, an
implementation may now choose to make checks even in the absence
of a SecurityManager.
Version 1.3 of this specification included an annotation
@javax.management.PropertyNames. In a class used within an MXBean
interface, this annotation established the connection between
constructor parameters and properties defined by getX()
or isX() methods. This annotation has been superseded by
the annotation @java.beans.ConstructorProperties
which has the same function for MXBeans but also a parallel
function for JavaBeans.