You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DeepEquals: Fix overly strict collection type comparison
- Fixed issue where Collections.unmodifiableCollection() results could not be compared with Lists
- Relaxed comparison logic to allow plain Collection vs List comparison as unordered collections
- Preserved important Set vs List distinction (still reports type mismatch)
- Added comprehensive test coverage for various unmodifiable collection types
- Fixes compatibility with json-io which converts unmodifiable collections to different types
This change allows DeepEquals to properly compare collections that have been serialized/deserialized
to different but compatible implementation classes, while still maintaining proper equality semantics
between incompatible collection types like Set and List.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: changelog.md
+10Lines changed: 10 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,10 @@
1
1
### Revision History
2
2
#### 4.0.1 (unreleased)
3
+
> ***FIXED**: `DeepEquals` collection comparison was too strict when comparing different Collection implementations:
4
+
> ***Fixed UnmodifiableCollection comparison**: Collections.unmodifiableCollection() results can now be compared with Lists/ArrayLists based on content
5
+
> ***Relaxed plain Collection vs List comparison**: Plain Collection implementations (not Set) are now compared as unordered collections with Lists
6
+
> ***Preserved Set vs List distinction**: Sets and Lists still correctly report type mismatch due to incompatible equality semantics
7
+
> ***Added comprehensive test coverage**: New test ensures various unmodifiable collection types compare correctly with their mutable counterparts
3
8
> ***FIXED**: `SafeSimpleDateFormat` thread-safety and lenient mode issues:
4
9
> ***Fixed NPE in setters**: Initialize parent DateFormat fields (calendar, numberFormat) in constructor to prevent NPEs when setters are called
5
10
> ***Fixed lenient propagation**: Ensure lenient setting is properly applied to both Calendar and SimpleDateFormat in State.build()
@@ -91,6 +96,11 @@
91
96
> ***Added special case handling for AtomicInteger and AtomicLong**: Use get() methods directly like AtomicBoolean, avoiding reflective field access for better performance and consistency
92
97
> ***Precompiled sensitive data regex patterns**: Avoid regex compilation overhead on every call to looksLikeSensitiveData() by using precompiled Pattern objects
93
98
> ***Added Enum handling as simple type**: Use reference equality (==) for enum comparisons and format as EnumType.NAME, avoiding unnecessary reflective field walking
99
+
> ***IMPROVED**: `ReflectionUtils` enhancements based on GPT-5 review:
100
+
> ***Fixed getMethod interface search**: Now properly searches entire interface hierarchy using BFS traversal to find default methods
101
+
> ***Removed pre-emptive SecurityManager checks**: Removed unnecessary SecurityManager checks from call() methods since setAccessible is already wrapped
102
+
> ***Documented null-caching requirement**: Added clear documentation to all cache setter methods that custom Map implementations must support null values
103
+
> ***Fixed getClassAnnotation javadoc**: Corrected @throws documentation to accurately reflect that only annoClass=null throws, classToCheck=null returns null
94
104
#### 4.0.0
95
105
> ***FEATURE**: Added `deepCopyContainers()` method to `CollectionUtilities` and `ArrayUtilities`:
96
106
> ***Deep Container Copy**: Iteratively copies all arrays and collections to any depth while preserving references to non-container objects ("berries")
0 commit comments