blerer opened a new issue, #15453:
URL: https://github.com/apache/lucene/issues/15453
### Description
The logic of `DataInput.readMapOfStrings` is the following:
```
public Map<String, String> readMapOfStrings() throws IOException {
int count = readVInt();
if (count == 0) {
return Collections.emptyMap();
} else if (count == 1) {
return Collections.singletonMap(readString(), readString());
} else {
Map<String, String> map = count > 10 ? new HashMap<>() : new
TreeMap<>();
for (int i = 0; i < count; i++) {
final String key = readString();
final String val = readString();
map.put(key, val);
}
return Collections.unmodifiableMap(map);
}
}
```
If the number of element is greater than 10, the map that is used will be a
TreeMap that will perfrom insert in O(log n) instead of an amortized O(1) and
the returned map (HashMap or TreeMap) will be wrapped in an unmodifiable one.
The issue is that the sort and the wrapping appear to be in practice useless
because `SegmentInfo` will perform a `Map.copyOf` on it (discarding the sort
and the wrapping). `FieldInfo` do not perform any operation on top of the Map
and expect an Unmodifiable `HashMap` (based on its code).
A similar thing happen with `DataInput.readSetOfStrings`
Based on those observations, it would make sense to remove the unecessary
sorting and standardize the code on either Unmodifiable Maps or ImmutableMaps.
`Maps.copyOf` is a noop on an `ImmutableMap`
Happy to provide a patch if the decision is to fix that logic. :-)
### Version and environment details
_No response_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
