* original, identical JDK TypeVariable. By doing so, we sidestep the problem entirely.
         *
         * 2b. If the resolved types are different from the original types, things are trickier. The
         * only way to get a TypeVariable instance for the resolved types is to create our own. The
         * created TypeVariable will not interoperate with any JDK TypeVariable. But this is OK: We

////

## HTML "abbr" 要素 { #html-abbr-elements }

//// tab | テスト

ここでは HTML の "abbr" 要素で包まれたものをいくつか示します（いくつかは架空です）:

### abbr が完全な語句を示す { #the-abbr-gives-a-full-phrase }

* <abbr title="Getting Things Done - 仕事を成し遂げること">GTD</abbr>
* <abbr title="less than - より小さい"><code>lt</code></abbr>
* <abbr title="XML Web Token - XML ウェブトークン">XWT</abbr>
* <abbr title="Parallel Server Gateway Interface - 並列サーバーゲートウェイインターフェース">PSGI</abbr>

  }

  // We use power-of-2 tables, and this is the highest int that's a power of 2
  static final int MAX_TABLE_SIZE = Ints.MAX_POWER_OF_TWO;

  // Represents how tightly we can pack things, as a maximum.
  private static final double DESIRED_LOAD_FACTOR = 0.7;

  // If the set has this many elements, it will "max out" the table size

		return i
	}
	if b.buf == nil && n <= smallBufferSize {
		b.buf = make([]byte, n, smallBufferSize)
		return 0
	}
	c := cap(b.buf)
	if n <= c/2-m {
		// We can slide things down instead of allocating a new
		// slice. We only need m+n <= c to slide, but
		// we instead let capacity get twice as large so we
		// don't spend all our time copying.
		copy(b.buf, b.buf[b.off:])

        }
      }
      return map.values();
    }

    private ImmutableList<Method> getVisibleMethods(Class<?> cls) {
      // Don't use cls.getPackage() because it does nasty things like reading
      // a file.
      String visiblePackage = Reflection.getPackageName(cls);
      ImmutableList.Builder<Method> builder = ImmutableList.builder();

             * request. However the chances are slim and the
             * retry code should ensure the overall request
             * is serviced. The alternative complicates things
             * more than I think is worth it.
             */

            if (this.socket != null) {
                this.socket.close();
                this.socket = null;
            }

    // This lock protects the task so we can ensure that none of the template methods (startUp,
    // shutDown or runOneIteration) run concurrently with one another.
    // TODO(lukes): why don't we use ListenableFuture to sequence things? Then we could drop the
    // lock.
    private final ReentrantLock lock = new ReentrantLock();

    @WeakOuter
    final class Task implements Runnable {
      @Override
      public void run() {

      totalCount += count;
      return this;
    }

    AvlNode<E> add(
        Comparator<? super E> comparator, @ParametricNullness E e, int count, int[] result) {
      /*
       * It speeds things up considerably to unconditionally add count to totalCount here,
       * but that destroys failure atomicity in the case of count overflow. =(
       */
      int cmp = comparator.compare(e, getElement());

 *       returns {@code true}.
 *   <li>A class which implements {@code Comparable<UnrelatedType>} is very broken, and will cause
 *       undefined horrible things to happen in {@code Range}. For now, the Range API does not
 *       prevent its use, because this would also rule out all ungenerified (pre-JDK1.5) data types.
 *       <b>This may change in the future.</b>
 * </ul>
 *

  <id>settings</id>
  <name>Settings</name>
  <description>
    <![CDATA[
    <p>This is a reference for the user-specific configuration for Maven.</p>
    <p>Includes things that should not be distributed with the <code>pom.xml</code> file, such as developer identity, along with
    local settings, like proxy information.</p>