accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ctubbsii <...@git.apache.org>
Subject [GitHub] accumulo pull request #279: ACCUMULO-3238 Table.ID Namespace.ID Refactor
Date Tue, 11 Jul 2017 17:26:32 GMT
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message