Repository navigation
Conversation
Array types resolved within a generic context (like field `T[]` or `Map[]` in `Foo<String>`) kept bindings of the enclosing type, which also leaked into raw element types, making them differ from the same array type resolved directly. Arrays are now always created with empty bindings, and are not cached so that an array whose element is a self-reference is not returned outside of its resolution context. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
c7aade0 to
75a3344
Compare
|
@PHJ2000 Happy to get this merged, but before doing that, I'll need CLA from https://github.com/FasterXML/jackson/blob/main/CLA-jackson-pre-2026.pdf (despite location, not Jackson-specific) and once I got it filled, signed, scanned/photo, email to Thank you again! |
|
I’ve sent the signed CLA to cla@fasterxml.com. Thank you! |
|
Wow. This open a BIG can of worms with Claude code reviews... uncovering a lot of issues to resolve. Getting there but took a while. |
Thanks for digging into this! If there’s anything I can help with, including testing or follow-up changes, I’d be happy to. |
Include the resolved element type in array equality and hashing. Tests cover equality, HashSet membership and cache separation for arrays whose erased classes match but whose generic element types differ.
Fixes #125.
Validation: Java 21 mvn verify: 262 tests, 0 failures/errors/skips.