clolov commented on code in PR #21726:
URL: https://github.com/apache/kafka/pull/21726#discussion_r2931105243
##########
clients/src/test/java/org/apache/kafka/common/feature/FeaturesTest.java:
##########
@@ -89,10 +88,8 @@ public void testFromFeaturesMapToFeaturesMap() {
public void testToStringSupportedFeatures() {
SupportedVersionRange v1 = new SupportedVersionRange((short) 1,
(short) 2);
SupportedVersionRange v2 = new SupportedVersionRange((short) 3,
(short) 4);
- Map<String, SupportedVersionRange> allFeatures
- = mkMap(mkEntry("feature_1", v1), mkEntry("feature_2", v2));
-
- Features<SupportedVersionRange> features =
Features.supportedFeatures(allFeatures);
+ Features<SupportedVersionRange> features = Features.supportedFeatures(
Review Comment:
I tried this with Map.of() only and it seemed to work - is there a reason
you rely on mkMap?
##########
clients/src/test/java/org/apache/kafka/clients/consumer/RangeAssignorTest.java:
##########
@@ -388,7 +387,7 @@ public void
testRackAwareStaticMemberRangeAssignmentPersistentAfterMemberIdChang
@Test
public void testRackAwareAssignmentWithUniformSubscription() {
- Map<String, Integer> topics = mkMap(mkEntry("t1", 6), mkEntry("t2",
7), mkEntry("t3", 2));
+ Map<String, Integer> topics = Utils.mkMap(Map.entry("t1", 6),
Map.entry("t2", 7), Map.entry("t3", 2));
Review Comment:
Could you refactor this so as to not depend on mkMap? I understand that
ordering here matters and we can't use Map.of because it randomises the
insertion, but I still think that if we are removing mkMap we ought to remove
it everywhere 😊
--
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]
