Ability to expire entries on map access instead of in scheduled executor

[qualidafial]

See jdbi/jdbi#1453 for reference.

In JEE container environments like Tomcat or Wildfly, one needs to design applications for so that app-specific threads are stopped and classes may be unloaded, so that everything from the old .war can be freed when a new .war is deployed. ExpiringMap's use of static ScheduledExecutorService to expire entries, and ThreadPoolExecutor to notify expiration listeners are correctly logged as a thread leak.

In order to facilitate class unloading, it would be nice if we could configure our expiring maps to perform expiration and listener notification on the calling thread, whenever the map is accessed.

[jhalterman]

This seems worth doing, but I'm not available atm. I'd be happy to take a PR for this though.

We could make the expirer (threadpool) configurable in the builder, where if one is supplied then the static EXPIRER doesn't need to be constructed. We can then have a member var inside the ExpiringMap that either points to the user provided expirer or the static one. Similar with expiration.

[qualidafial]

In the intervening months since reporting this issue, we have sadly found it necessary to remove expiringmap from Jdbi, in favor of our own naive caching solution. It is unlikely any of us will be able to devote the time for a PR.

Thank you for the follow up.

[jhalterman]

No worries @qualidafial - hope it's working well for you 👍(random aside, I've used JDBI a lot in the past and really enjoy it).