rondagostino commented on PR #13280: URL: https://github.com/apache/kafka/pull/13280#issuecomment-1500610824
> Also, as you yourself argued, converting back to java.util.Map loses type safety, since now we don't know if we have a persistent map or not. It is quite useful to know that your map is immutable, even if I doubt that confusion between regular types and persistent ones will be as common as you suggest. Yeah, I was including `.asJava()` really only as a way to not have to change our existing type return values. If something returns a `java.util.Map<>` and now we are implementing the logic with persistent data structures, do we want to change that signature to indicate that the returned map is persistent? When we weren't considering the use of a wrapper class it was very intrusive to change the signature to say we are now returning a Vavr map -- the ripple effects went everywhere. But I guess this does argue for implementing the standard interfaces in the wrapper. It would allow us to change the signature but downstream code is unaffected. That code might declare `Map<Class1, Class2> x = someObject.someMethod()` and that will still compile when we declare `someMethod()` to return a wrapper class when that wrapper class implements `java.util.Map`. That insulates us from ripple-effect changes while simultaneously giving callers the option to actually know that the map is a persistent one. I think this is the argument that convinces me to implement the standard interfaces in the wrapper classes. I'll add it now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
