RFR: 8358701: Java API docs for javax.management.remote should not link to JMXMP

Alan Bateman alanb at openjdk.org
Fri Jun 6 08:33:53 UTC 2025


On Fri, 6 Jun 2025 08:18:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Doc-only cleanup, not part of the API/spec.
>> 
>> Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.
>
> src/java.management/share/classes/javax/management/remote/package-info.java line 56:
> 
>> 54:  *     JMXConnectorFactory} and, optionally, the Generic Connector
>> 55:  *     (not part of this bundle, see note below).
>> 56:  *     </ul>
> 
> I wonder if we should keep the first part of the note - without the link. Something like:
> 
> 
>  *
>  *       <p><u>Note</u>: The historical JMX Remote API specification
>  *         also defined an optional part; optional packages implementing
>  *         the optional part of the <em>JMX Remote API</em>
>  *         are not part of the <em>Java SE Platform</em>.</p>
>  *
>  ```
>  
>  @AlanBateman do you think that would be helpful to keep?

What would you think about dropping the sentence "The JMX Remote API allows the use of different type of connectors" and drop "User-defined" from the last list item?  Doing that makes it much easier to say that the RMI Connector is standard and that other Connectors are possible using using the JMXConnectorFactory. It removes any discussion as to whether there are two or three "difference types".

I think we want "RMI Connector" to link to either RMIConnector or to the java.management.rmi module description.

My concern with having a historical note is that it invites readers to search for these other "interesting" optional parts, and they will be disappointed. If you do have a historical note then I think it need to say more than "are not part of the Java Platform", it will also need to say that they are not included in the JDK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25670#discussion_r2131764059


More information about the serviceability-dev mailing list