How can we find hot paths in a Java library we own but don't consume?

Start with the biggest consumers and ask what performance problems they actually see. A CPU hotspot in one application may not matter much in another, so getting a few profiles alongside the workload context is more useful than treating them as one universal ranking.

If nobody has reported a problem, decide what you're trying to improve before spending a lot of time optimizing. HotSpot also optimizes code based on how the application runs it, which makes representative workloads valuable.

Telemetry could help fill the gap, especially around public library operations. Counts and timing distributions can show which operations are common or slow across participating consumers, though they won't replace a CPU profile for finding expensive internal call paths.

Keep the instrumentation lightweight and coordinate with consumers on overhead, data access, and what gets collected. You'll still need to account for environments that don't enable it.

This sounds partly like a tooling problem. Talk to the team responsible for the company profiler about a library-centric view or a way to aggregate profiles from onboarded environments. That won't magically cover teams that haven't onboarded, but it could make the data you do have much easier to use.