21 test fix #391
21 test fix #391
Conversation
Unit Test Results 🚀658 tests ±0 657 ✅ ±0 3m 3s ⏱️ +4s For more details on these failures, see this check. Results for commit 42523dc. ± Comparison against base commit eefbdfb. ♻️ This comment has been updated with latest results. |
| @@ -49,8 +50,14 @@ public void tearDown() { | |||
| assertEquals(req2, reqs1[1]); | |||
| assertEquals(req3, reqs1[2]); | |||
|
|
|||
| req3 = "ff=bb&68=45&device_id=55"; | |||
| req2 += "&old_device_id=" + did; | |||
| if (Build.VERSION.SDK_INT >= 21 && Build.VERSION.SDK_INT <= 25) { | |||
There was a problem hiding this comment.
what is this one about
There was a problem hiding this comment.
I don't know after 25 they probably changed iteration for maps
There was a problem hiding this comment.
must be documentation somewhere about it. would be nice if you find. Also isnt 21 our min target, ide giving error when you omit that check?
There was a problem hiding this comment.
yeap 21 is our min target, is it Interesting it does not give on my side
There was a problem hiding this comment.
In API level 21, both HashMap and ConcurrentHashMap rely purely on a linked-list-based structure to resolve hash collisions (i.e., chaining). Migrating key-value pairs from ConcurrentHashMap to HashMap could lead to different bucket placements due to different internal bucket sizing, hash functions, or the way collisions are resolved.
Starting with Java 8 (introduced in Android API level 24), HashMap and ConcurrentHashMap both use improved hashing strategies and adopt tree-based nodes (red-black trees) for handling hash collisions when a bucket contains many entries. This makes the bucket handling more predictable and consistent, especially when the map grows or experiences collisions.
No description provided.