*       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

 * second invocation, so implementors have made various choices, including:
 *
 * <ul>
 *   <li>returning the same iterator again
 *   <li>throwing an exception of some kind
 *   <li>or the usual, <i>robust</i> behavior, which all known {@link Collection} implementations
 *       have, of returning a new, independent iterator
 * </ul>
 *
 * <p>Because of this situation, any public method accepting an iterable should invoke the {@code

	KNAME=$(uname -s)
	ARCH=$(uname -m)
	case "${KNAME}" in
	SunOS)
		ARCH=$(isainfo -k)
		;;
	esac
}

## FIXME:
## In OSX, 'readlink -f' option does not exist, hence
## we have our own readlink -f behavior here.
## Once OSX has the option, below function is good enough.
##
## readlink() {
##     return /bin/readlink -f "$1"
## }
##
readlink() {
	TARGET_FILE=$1

	cd $(dirname $TARGET_FILE)

/**
 * Form for uploading search request files to the Fess search engine.
 * This form is used in the admin interface to upload search request configuration files
 * that define search behaviors and request handling.
 */
public class UploadForm {

    /**
     * The multipart file containing the search request configurations to be uploaded.

        assertEquals(msg, ex.getMessage(), "Constructor should preserve the provided message (including null)");
        assertNull(ex.getCause(), "No cause expected when only message is provided");

        // toString behavior mirrors Throwable: includes message when not null
        String ts = ex.toString();
        assertTrue(ts.contains("SmbUnsupportedOperationException"), "toString should contain class name");
        if (msg != null) {

         * implementation of TypeVariable, but the behavior of the built-in implementation differs
         * across platforms:
         *
         * - Under the JDK, the built-in TypeVariable's equals() method doesn't recognize instances
         *   of our TypeVariable implementation.
         *
         * - Under Android, it does.
         *
         * We want users to see the same behavior when they compare a built-in TypeVariable against

        if (useAll) {
            return true;
        }

        // Check specific option
        if (specificOption.isPresent()) {
            return specificOption.get();
        }

        // Apply default behavior when no specific options are provided
        if (defaultWhenNoOptionsSpecified
                && options.infer().isEmpty()
                && options.model().isEmpty()
                && options.plugins().isEmpty()

                CollectionFeature.SERIALIZABLE,
                CollectionSize.ANY)
            .createTestSuite());
    suite.addTestSuite(HashMultimapTest.class);
    return suite;
  }

  /*
   * The behavior of toString() is tested by TreeMultimap, which shares a
   * lot of code with HashMultimap and has deterministic iteration order.
   */
  public void testCreate() {

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

                CollectionFeature.SERIALIZABLE,
                CollectionSize.ANY)
            .createTestSuite());
    suite.addTestSuite(HashMultimapTest.class);
    return suite;
  }

  /*
   * The behavior of toString() is tested by TreeMultimap, which shares a
   * lot of code with HashMultimap and has deterministic iteration order.
   */
  public void testCreate() {