Hi Alan- I agree the complex object marshaling using Serialization is not a great approach. Exposing metrics using primitives and having tools scrape JMX (like prometheus) is a nice simple pattern to provide metrics from Java applications.
We also see more instances of returning complex payloads as JSON from a string field or string operation to get away from complex object serialization. Summarizing a forward-looking use case: 1. Encourage use of primitives (not Serialized complex objects) 2. Support for simple JMXMP (start deprecating or discouraging JMX RMI) @Kevin- Thoughts? Thanks, Matt > On Jun 17, 2026, at 3:21 AM, Alan Bateman <[email protected]> wrote: > > On 16/06/2026 17:59, Matt Pavlovich wrote: >> I’m working on modernizing some JMX connectivity options and uncovered that >> it appears that using two-way SSL/TLS does not have a long runway with the >> current JDK, since ThreadLocal would be the only feasible technical approach. >> >> Going a step further, it does seem that jmxmp or a jmxmp-like connector >> shipped in the JDK would be a better longer term option as it removes the >> pain with the two-port solution with JMX RMI. >> >> To that end, I’d look to create a PR with an updated JMXMP provider for >> client and server. >> > There is interest in eventually moving away from the RMI Connector, one > reason being that RMI uses serialization. I think having something along the > lines of the "Generic Connector" with the JMXMP protocol has been discussed. > Kevin might more to say on this. Due to its significance then a move like > this would likely involve a JEP. > > -Alan
