* invoke methods, they invoke methods on the {@code ForwardingMultiset}.
 *
 * <p>The {@code standard} methods and any collection views they return are not guaranteed to be
 * thread-safe, even when all of the methods that they depend on are thread-safe.
 *
 * @author Kevin Bourrillion
 * @author Louis Wasserman
 * @since 2.0
 */
@GwtCompatible
public abstract class ForwardingMultiset<E extends @Nullable Object> extends ForwardingCollection<E>

 * violate the {@code Set} contract.
 *
 * <p>The {@code standard} methods and the collection views they return are not guaranteed to be
 * thread-safe, even when all of the methods that they depend on are thread-safe.
 *
 * @author Mike Bostock
 * @author Louis Wasserman
 * @since 2.0
 */
@GwtCompatible
/*
 * We provide and encourage use of ForwardingNavigableSet over this class, but we still provide this

 * invoke methods, they invoke methods on the {@code ForwardingSortedMultiset}.
 *
 * <p>The {@code standard} methods and any collection views they return are not guaranteed to be
 * thread-safe, even when all of the methods that they depend on are thread-safe.
 *
 * @author Louis Wasserman
 * @since 15.0
 */
@GwtCompatible
public abstract class ForwardingSortedMultiset<E extends @Nullable Object>

    }

    @Override
    protected Runnable wrapTask(Runnable command) {
      return new WrappedRunnable(command);
    }
  }

  // TODO: If this test can ever depend on Mockito or the like, use it instead.
  private static final class MockExecutor implements ExecutorService {
    private String lastMethodCalled = "";
    private long lastTimeoutInMillis = -1;

   *
   * <p><b>Warning: do not depend</b> on the behavior of this method.
   *
   * <p>Historically, {@code Equivalence} instances in this library have implemented this method to
   * recognize certain cases where distinct {@code Equivalence} instances would in fact behave
   * identically. However, as code migrates to {@code java.util.function}, that behavior will
   * disappear. It is best not to depend on it.
   */
  @Override

## Documenting the callback { #documenting-the-callback }

The actual callback code will depend heavily on your own API app.

And it will probably vary a lot from one app to the next.

It could be just one or two lines of code, like:

```Python
callback_url = "https://example.com/api/v1/invoices/events/"

 * 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.codelibs.fess;

// DO NOT DEPEND OTHER JARs

import java.io.File;
import java.util.List;
import java.util.Properties;

import org.apache.catalina.Container;
import org.apache.catalina.Context;
import org.apache.catalina.Host;

    <plexus-io.version>3.6.0</plexus-io.version> <!-- We need at least 3.5.1 to avoid https://github.com/codehaus-plexus/plexus-io/issues/109. Once we upgrade maven-jar-plugin itself to a version new enough to depend on 3.5.1 or higher, we can remove this override. -->
    <toolchains-maven-plugin.version>4.5.0</toolchains-maven-plugin.version>
    <truth.version>1.4.5</truth.version>

 * directory to a method in the application interface?
 *
 * - research extension points versus plugins
 *
 * from igor: two plugins A and B, both depend on the same library but use different versions, say
 * lib 1.0 and lib 2.0 when debugger hits a breakpoint inside a class from the library, IDE needs to
 * know which version of library the class comes from
 */

   *
   * <p><b>Warning: do not depend</b> on the behavior of this method.
   *
   * <p>Historically, {@code Converter} instances in this library have implemented this method to
   * recognize certain cases where distinct {@code Converter} instances would in fact behave
   * identically. However, this is not true of {@code Converter} implementations in general. It is
   * best not to depend on it.
   */
  @Override