This sounds like an honest bug that should be fixed, backwards compatibility be damned. I don't see how the old behavior is useful for anything other than connection starvation or some other strange behavior.
On 7 June 2018 at 10:44, Gary Gregory <garydgreg...@gmail.com> wrote: > Hi All: > > I just ran into a case where different instances of subclasses > of DelegatingConnection like PoolGuardConnectionWrapper and ConnectionImpl > are used as keys in a Map (Map<java.sql.Connection, Foo>) > > The problem is that when you borrow a Connection out of a pool, you get a > new PoolGuardConnectionWrapper, so that the Map in the eventual call site > grows and grows because the intention is that the Map key should be the > same when you borrow the same underlying Connection later. > > If DelegatingConnection implemented hashCode() and equals() to account for > some or all of its instance variables, then one could use > DelegatingConnection instances as keys in a Map with the behavior I expect, > YMMV. > > The issue is that implementing hashCode() and equals() where we did not > before could have unexpected side-effects for existing applications. > > Thoughts? > > Gary > -- Matt Sicker <boa...@gmail.com>
