cmccabe commented on code in PR #14290:
URL: https://github.com/apache/kafka/pull/14290#discussion_r1377982321
##########
server-common/src/main/java/org/apache/kafka/common/DirectoryId.java:
##########
@@ -16,55 +16,166 @@
*/
package org.apache.kafka.common;
+import java.util.ArrayList;
+import java.util.Arrays;
import java.util.Collections;
+import java.util.HashMap;
import java.util.HashSet;
+import java.util.List;
+import java.util.Map;
import java.util.Set;
-public class DirectoryId {
+public class DirectoryId extends Uuid {
Review Comment:
It's a Uuid in every single way other than having 100 reserved entries at
the beginning. I don't think that is enough to motivate a new type. A new type
would be inconsistent with how we do everything else (cluster IDs, incarnation
IDs, topic IDs, etc.) We use Uuid for all of them and there has never been any
confusion.
(Although cluster ID is kind of a miss because technically it's a string and
doesn't have to be a Uuid! But it was created before my time :) )
Having to copy between types is messy and confusing. For example, we'd have
to copy between types every time we serialize to a record or to an RPC. This
also removes a lot of the advantages you are touting (like "can't use
Uuid.randomUuid" since we have to deal with Uuids anyway.)
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
