Hi Benedikt, I made the decision to inherit from ConcurrentHashMap because the original implementation was inheriting from HashMap. I was doing an incremental refactoring approach and there was never a good justification for that design rather I was trying to make evolutionary improvements. Being able to plug in any map implementation would be a far better design. As for the original design decision to use a HashMap, I have no insight. There were quite a few design enigmas that I encountered, however if you look at the date of the original project I don't think it is unusual.
Best of luck, -Elijah On Tue, Jun 25, 2013 at 11:24 AM, Benedikt Ritter <benerit...@gmail.com>wrote: > I have created CHAIN-101 [1] > > Benedikt > > [1] https://issues.apache.org/jira/browse/CHAIN-101 > > Am 24.06.2013 um 20:57 schrieb Adrian Crum < > adrian.c...@sandglass-software.com>: > > > I have always preferred the "has-a" approach over the "is-a" approach. > It makes things easier to refactor down the road. > > > > -Adrian > > > > On 6/24/2013 7:30 PM, Benedikt Ritter wrote: > >> Hi, > >> > >> I just wonder why ContextMap inherits from ConcurrentHashMap. This > seems like an unnecessary restriction. The context interface makes > explicit, that implementations do not have to be thread safe. Beside that > we loose all thread safety a ConcurrentHashMap provides with our > not-so-thread-safe implementations in ContextMap and ContextBase. I'd > suggest to switch from an inheritance based approach to a delegation based > approach. That leaves users with the liberty to choose what ever underlying > Map implementation they like for their context. > >> > >> WDYT? > >> Benedikt > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- -Elijah
