How can we identify hot paths in a Java library used by other teams?

For suspected dead code, a temporary removal or a deliberately obvious failure can act as a ‘scream test’: remove the path, deploy it to a safe group, and see whether consumers report problems. That’s risky in production, so feature flags, staged rollouts, and deprecation notices are safer ways to confirm whether an API or code path is still in use.

If the library team needs ongoing visibility, add carefully designed telemetry rather than relying only on occasional profiling dumps. For example, record anonymized usage counters, operation frequencies, timings, and client identifiers through an approved logging or metrics pipeline. Make sure the overhead, privacy implications, and opt-out behavior are understood. This won’t replace full profiling, but it can show which APIs and code paths are actually exercised.

The cleanest solution is probably an organization-wide profiling data store. Have each team upload JFR recordings or other profiler output to a shared object store, then run analysis jobs over the recordings. Since stack frames include fully qualified class and method names, you can filter for your library and aggregate the hot methods across applications. You’ll still have some selection bias because not every consumer will provide data, but this gives you a much broader view than examining one environment at a time.

Java Flight Recorder can make this fairly low effort. Consumers can enable the appropriate JFR options at startup or on demand, export the recording, and provide it to your team for analysis in tools such as JDK Mission Control or VisualVM. You may need to adjust the recording settings so the events and stack information you care about are captured. Automating collection and upload would make this practical at scale.

Before optimizing broadly, make sure there is an actual performance problem to solve. Ask major users whether they are seeing latency, CPU, or allocation issues and work with them on a representative workload. You can also build a small application around the library and load-test it, but results from that setup may not reflect how consumers use it in production. If there is a known issue, the affected team is usually the best source of a recording.