I agree with Ralph. 

I am working on custom implementations of ThreadContextMap (LOG4J2-1010, LOG4J2-1447, LOG4J2-1349) and I'm very glad the interface is small. 

My rule of thumb for API design is YAGNI: don't add until you really need it, otherwise it'll get in the way. 


Sent from my iPhone

On 2016/08/21, at 4:59, Ralph Goers <ralph.goers@dslextreme.com> wrote:

1. Why?  
2. Why do you need to implement equals and hashcode? What other map are you going to compare it with?
2. Which version? Java 8 added a bunch of new methods.

I don’t really view the thread context map as a Map. It is really nothing more than a bunch of keys and values that I want to store that are probably not really directly related with each other, much like HTTP session attributes.  When there are cases of wanting to iterate through the whole map we first get a copy of it.


On Aug 20, 2016, at 11:01 AM, Gary Gregory <garydgregory@gmail.com> wrote:

Fair enough.

I am wondering if there is a design reason not to implement Map now that we have the opportunity with the TCM2 interface. I'd take a crack at it.


On Aug 20, 2016 10:39 AM, "Ralph Goers" <ralph.goers@dslextreme.com> wrote:
Because Map has a lot more methods that weren’t needed and I didn’t want to implement?


On Aug 20, 2016, at 10:16 AM, Gary Gregory <garydgregory@gmail.com> wrote:

Hi All:

Now that we have ThreadContextMap2:

Why don't we do ThreadContextMap2 extends Map<String, String>?

Why did ThreadContextMap initially not extends Map<String, String>?