Filters scans service loader over and over

[aaime]

Versions impacted by the bug

5.x

What went wrong?

While profiling the netcdf library I've noticed that the Filters.getFilter method shows up in the profile as a time sync, in particular, the bits calling onto ServiceLoader.

Suggestions: at a minimum, call onto the service loader only once in the method. For bonus points, perform the classpath scan only once in a static initializer, save in an immutable list, and just reuse over and over the results.
While it's possible to dynamically add class loaders at runtime, potentially fetching from jars that were not part of the classpath defined at JVM startup, this seems like a minority case, and maybe a "reload" method could be added to care for that subset of case.

Relevant stack trace

No response

Relevant log messages

No response

If you have an example file that you can share, please attach it to this issue.

If so, may we include it in our test datasets to help ensure the bug does not return once fixed?
Note: the test datasets are publicly accessible without restriction.

Yes

Code of Conduct

• I agree to follow the UCAR/Unidata Code of Conduct

[aaime]

Oh, BTW, if you agree with any of the suggestions, I'm happy to follow up with a PR.

[haileyajohnson]

Thanks for the insight! We'd love a PR if you're able.

[aaime]

Would you be ok with the "load list once on class initialization, and expose a reset/reload method for the oddball cases where the classpath is modified at runtime"?