JDK-6750008 : Add JMX.getSpecificationVersion(MBeanServerConnection) and document interop constraints
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 6,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-09-18
  • Updated: 2017-05-16
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b41Fixed
Related Reports
Duplicate :  
Relates :  
Description
When a JMX 2.0 client is talking to a server that might be running an earlier version of the JMX spec, it must be careful to avoid features that that earlier version did not support. To make it easier to do this, we should define a new method JMX.getSpecificationVersion(MBeanServerConnection) which returns the version of the JMX spec from the MBeanServer at the other end of the connection, or null if it is not known. A reminder that this version is available from the SpecificationVersion attribute of the MBeanServerDelegate. It is a string, in the format defined by java.lang.Package. The only legal values today are "1.0", "1.1", "1.2", and "1.4". (Yes, there is no 1.3.) With the completion of JSR 255, there will be an additional possibility, "2.0".

These specification versions have the property that String.compareTo works in the expected way. We can guarantee that any future version will too. In the extremely unlikely event that we someday need a successor to version 2.9, and we don't want to call it 3.0, then we can call it version 2.9+ or 2.9a or 2.a10 or whatever.

The specification should detail what features you lose when you are talking to 1.4, and what further features you lose when you are talking to 1.2. Since the JMX Remote API requires at least 1.2, we don't need to list what you lose beyond that.

Here is a first cut at such a list:
If the remote MBean Server is 1.4

    * You cannot use QueryNotificationFilter in addNotificationListener.
    * In an attribute in a query, you cannot access values inside complex types using dot syntax, e.g. HeapMemoryUsage.used.
    * The packages javax.management.event and javax.management.namespace do not exist, so you cannot create instances of the MBeans they define.
    * Even if the remote MBean Server is 2.0, you cannot in general suppose that EventClient or ClientContext will work with it without first checking. If the remote MBean Server is 1.4 then those checks will return false, and an attempt to use these features without checking will fail in the same way.

If the remote MBean Server is 1.2

In addition to the above,

    * You cannot use wildcards in a key property of an ObjectName, for example domain:type=Foo,name=*. Wildcards that match whole properties are still allowed, for example *:* or *:type=Foo,*.
    * You cannot use Query.isInstanceOf in a query.
    * You cannot use dot syntax such as HeapMemoryUsage.used in the observed attribute of a monitor.

Comments
EVALUATION Implementing the method is trivial. Making sure the lists are exhaustive is slightly less so.
18-09-2008