Github user ctubbsii commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/279#discussion_r126755404
--- Diff:
core/src/main/java/org/apache/accumulo/core/client/impl/AbstractId.java ---
@@ -0,0 +1,86 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.accumulo.core.client.impl;
+
+import static java.nio.charset.StandardCharsets.UTF_8;
+import static java.util.Objects.requireNonNull;
+
+import java.io.Serializable;
+import java.util.Objects;
+
+/**
+ * An abstract identifier class for comparing equality of identifiers of
the same type.
+ */
+public abstract class AbstractId implements Comparable<AbstractId>,
Serializable {
+
+ private static final long serialVersionUID = -155513612834787244L;
+ private final String canonical;
+ private Integer hashCode = null;
+
+ protected AbstractId(final String canonical) {
+ requireNonNull(canonical, "canonical cannot be null");
+ this.canonical = canonical;
+ }
+
+ /**
+ * The canonical ID
+ */
+ public final String canonicalID() {
+ return canonical;
+ }
+
+ public boolean isEmpty() {
+ return canonical.isEmpty();
+ }
+
+ /**
+ * AbstractID objects are considered equal if, and only if, they are of
the same type and have the same canonical identifier.
+ */
+ @Override
+ public boolean equals(final Object obj) {
+ return obj != null && Objects.equals(getClass(), obj.getClass()) &&
Objects.equals(canonicalID(), ((AbstractId) obj).canonicalID());
+ }
+
+ @Override
+ public int hashCode() {
+ if (hashCode == null) {
+ hashCode = Objects.hash(canonicalID());
+ }
+ return hashCode;
+ }
+
+ /**
+ * Returns a string of the canonical ID
+ */
+ @Override
+ public String toString() {
+ return canonical;
+ }
+
+ /**
+ * Return a UTF_8 byte[] of the canonical ID.
+ */
+ public final byte[] getUtf8Bytes() {
+ return canonical.getBytes(UTF_8);
--- End diff --
One reason not to use `getBytes` is that because of the encoding issues
that plague current methods with that name, the name `getBytes` is almost
always a red flag that encoding has been overlooked. Concretely selecting a
different name communicates to the developer reading calls to it that they
don't need to stop and double-check the docs and/or implementation to ensure
encoding is handled correctly.
Another reason to avoid the common name. Searching for references in IDEs
like Eclipse will also turn up thousands, if not millions, of false positive
matches from `String.getBytes()` and others.
I'd almost prefer `getUtf8()` over `getBytes`.
I believe this method only exists as a convenience method for constructing
metadata rows. It can probably be removed from this class, and be pushed down
into the metadata code where it's needed. Keep the serialization with the
storage, is probably preferred in this case, than keeping the serialization
with the object.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
