private int value;

    @Override
    public Integer get() {
      return ++value;
    }

    @Override
    public boolean equals(@Nullable Object obj) {
      if (obj instanceof CountingSupplier) {
        return this.value == ((CountingSupplier) obj).value;
      }
      return false;
    }

    @Override

name: Feature Addition Request
description: I want to add a new feature
labels: ["type=addition"]
body:
  - type: markdown
    attributes:
      value: >
        Filing feature requests is one of the most popular ways to contribute to Guava.


        Be aware, though: most feature requests are not accepted, even if they're suggested by
        a full-time Guava team member. [Feedback](https://stackoverflow.com/a/4543114) from our

        for (final Enumeration<String> e = bundle.getKeys(); e.hasMoreElements();) {
            final String key = e.nextElement();
            final String value = bundle.getString(key);
            ret.put(key, value);
        }
        return ret;
    }

    /**
     * Converts the resource bundle to a {@link Map} and returns it.
     *

<div class="wrapper">
    <jsp:include page="/WEB-INF/view/common/admin/header.jsp"></jsp:include>
    <jsp:include page="/WEB-INF/view/common/admin/sidebar.jsp">
        <jsp:param name="menuCategoryType" value="system"/>
        <jsp:param name="menuType" value="dict"/>
    </jsp:include>
    <main class="content-wrapper">
        <div class="content-header">
            <div class="container-fluid">
                <div class="row mb-2">

   * next} field is lazily initialized. The type of that field would be {@code @Nullable T}, and the
   * code would be responsible for populating a "real" {@code T} (which might still be the value
   * {@code null}!) before returning it to callers. Depending on how the code is structured, a
   * nullness analysis might not understand that the field has been populated. To avoid that problem

          collection.remove(e3()));
    } catch (UnsupportedOperationException tolerated) {
    }
    expectUnchanged();
    expectMissing(e3());
  }

  @CollectionFeature.Require(value = SUPPORTS_REMOVE, absent = ALLOWS_NULL_QUERIES)
  public void testRemove_nullNotSupported() {
    try {
      assertFalse(
          "remove(null) should return false or throw NullPointerException",

   * next} field is lazily initialized. The type of that field would be {@code @Nullable T}, and the
   * code would be responsible for populating a "real" {@code T} (which might still be the value
   * {@code null}!) before returning it to callers. Depending on how the code is structured, a
   * nullness analysis might not understand that the field has been populated. To avoid that problem

        </ul>
    </div>
    <div id="content"></div>
    <div id="form">
        <form method="post" action="form.html">
            <input type="text" name="query" value="aaa">
            <input type="hidden" name="secret" value="xxx">
            <input type="submit" name="Submit">
        </form>
    </div>
	<a href="#" onclick="addFooter('XXX')">Footer</a>
	<div id="footer">
	</div>
</body>

@SuppressWarnings("JUnit4ClassUsedInJUnit3")
public class AbstractSetTester<E> extends AbstractCollectionTester<E> {
  /*
   * Previously we had a field named set that was initialized to the value of
   * collection in setUp(), but that caused problems when a tester changed the
   * value of set or collection but not both.
   */
  protected final Set<E> getSet() {
    return (Set<E>) collection;
  }

{
    "properties": {
      "crawlingInfoId": {
        "type": "keyword"
      },
      "key": {
        "type": "keyword"
      },
      "value": {
        "type": "keyword"
      },
      "createdTime": {
        "type": "long"
      }
    }