Inconsistencies between isMap() and how the the type is treated

[nexx512]

Class ParameterizedTypeInformation:
isMap() is true for Vavr maps but in some Function the type is treated like a java map.
See #2517 for more details
This leads to Problems with aggregates using vavr maps for mongodb

[odrotbohm]

Closing in favor of #2517. Even if not an exact duplicate, we need to cover the Vavr collections and maps story as a whole.

[nexx512]

Are there chances that this will be fixed soon? Right now we are stuck with Spring 2.5.x and can't update our project to newer Spring versions.

[odrotbohm]

Care to elaborate? Vavr Map types so far have always only been completely supported as repository return types. Implementing support for those in our object mapping is not a trivial effort and definitely not done by only tweaking TypeDiscoverer. We're currently investigating this but are not yet decided whether we want to support this at all.

[nexx512]

Thank you for your explanation. I think there are a couple of issues that are a bit mixed up right now. Let me try to clarify this.

I did send a couple merge requests regarding Vavr type mapping. These are meant for discussion. My main focus was not to implement Vavr object mapping in SD but to simplify the usage of custom type mappers (I refer to #3912 and #2511). But actually, this is not a problem for us right now. By writing a custom Mapper class derived from MappingMongoConverter and a few custom Converters, we got that covered and even implemented complex map types. This works fine right now.

But now to the real issue we have:

Right now we use Spring Boot 2.5.9. But when I update our project to Spring Boot 2.6.3 I get the error Can't retrieve super type information for interface java.util.Map! Does current type really implement the given one? when starting the application. Tracking that error down, i saw that in ParameterizedTypeInformation class the function doGetComponentType() first checks for a map type using the isMap() function. This is true for vavr maps. But then the function throws an exception if the map type can not be cast to java.util.Map. That the inconsistency I wanted to point out and thats what the change in #2517 class ParameterizedTypeInformation` is for. This PR is completely independent from the other ones and has nothing to do with object mapping in general. Since our application doesn't even start with Spring Boot 2.6.3 due to this exception I can not find a way to make it work.

The change in #2517 class TypeDiscoverer adresses problems with type detections for vavr map classes. The generic types are not detected correctly. We need this information in our custom mapping class, but found some workarounds. However it would be nice if TypeDiscoverer would give us correct generic types.

So for us the issue in ParameterizedTypeInformation is a real show stopper right now that blocks updates. I can't tell the whole impact but I would guess that the changes I propose should not affect current implementations with java.util.Map classes.

So would it be possible to accept the changes in #2517 (or even only the changes in ParameterizedTypeInformation - I can create a separate pull request if needed) independently of the discussion about vavr object type mapping?