[JAVA-5287] Regression (4.9.x to 4.11.x) lack of generic support in Maps Created: 05/Jan/24 Updated: 04/Feb/24 |
|
| Status: | Waiting for Reporter |
| Project: | Java Driver |
| Component/s: | None |
| Affects Version/s: | 4.11.0, 4.11.1, 4.11.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Unknown |
| Reporter: | Robert Fox | Assignee: | Ross Lawley |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
Summary4.9.x versions of the Java driver would handle this scenario gracefully: A class with a property like: public Map<String, MyGenericType<Animal>> decorators; where Animal is an abstract class with a discriminator. Such a field in a class now produces: CodecConfigurationException with the message: "[x] contains generic types that have not been specialised. Top level classes with generic types are not supported by the PojoCodec." Please provide the version of the driver. If applicable, please provide the MongoDB server version and topology (standalone, replica set, or sharded cluster).Version 4.11.x of the Java driver produces the error. Version 4.9.x of the driver works fine. This is also affecting a widely used Java library, Quarkus: https://github.com/quarkusio/quarkus/issues/36397
|
| Comments |
| Comment by Oleg Toubenshlak [ 04/Feb/24 ] |
|
I do have, but extracting separate examples from the full infra we built is a bit complicated. I will do it if there is no other candidate, but it will take some time...
Thanks
|
| Comment by Jeffrey Yemin [ 28/Jan/24 ] |
|
If anyone has a reproduction of this issue that is independent of Quarkus, we'd love to see it. |
| Comment by Oleg Toubenshlak [ 28/Jan/24 ] |
|
Hi, we have the same issue. Is there any progress on it?
Thanks! |
| Comment by Robert Fox [ 09/Jan/24 ] |
|
Got it–will provide both reproductions. But it will have to wait about a week! |
| Comment by Tom Selander [ 08/Jan/24 ] |
|
Hi robert@unitydynamics.com, this second issue with DecoratorBase sounds like it can be a second ticket. If you can file an additional ticket for this behavior (with a repro) we will look into it. If you could also add the repro for this ticket as well, we can investigate this one too. Thanks Robert! |
| Comment by Robert Fox [ 08/Jan/24 ] |
|
Thanks Ross. As I was creating a reproduction example I noticed it's very much an edge case that we can work around. Our new strategy is to use a non-generic abstract base class in our maps: public Map<String, DecoratorBase> decorators; and then make a generic class underneath: public abstract class DecoratorBase { }; public class Decorator<? extends Animal> extends DecoratorBase ... The problem we run into now is that when you register the package with all of the classes in it, DecoratorBase is not found (presumably because map value classes are not scanned when ordering classes for registration?) If we explicitly register DecoratorBase, then the code works as expected. Because the issue is slightly different for us now should we close this issue or rename it? I don't mind opening a new ticket. Thanks again, -Robert
|
| Comment by Ross Lawley [ 05/Jan/24 ] |
|
Many thanks for the ticket. Could you provide more detail on the bug? Either a full stacktrace or a test case to reproduce the error. Ideally, a minimal reproducible example would help as I could replicate the bug and use it as a test case for the fix. All the best, Ross |
| Comment by PM Bot [ 05/Jan/24 ] |
|
Hi robert@unitydynamics.com, thank you for reporting this issue! The team will look into it and get back to you soon. |