}

    @Test
    @DisplayName("Invalid: resolving class by null name throws NPE")
    void testClassForNameWithNull() {
        // Intent: demonstrate defensive behavior with null when resolving this type by name
        assertThrows(NullPointerException.class, () -> Class.forName(null));
    }

    @Test
    @DisplayName("Happy path: class is loadable via fully qualified name")

 *       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},

 *       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() {

                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},

        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()

				t.Error(err)
			}
			fs.Delete(context.Background(), "voldir", test.objName, DeleteOptions{
				Recursive: false,
				Immediate: false,
			})
		})
	}
}

// Test to validate xlStorage behavior on windows when a non-final path component is a file.
func TestUNCPathENOTDIR(t *testing.T) {
	// Instantiate posix object to manage a disk
	dir := t.TempDir()

	fs, err := newLocalXLStorage(dir)
	if err != nil {

import java.util.Set;
import org.jspecify.annotations.Nullable;

/**
 * A multimap which forwards all its method calls to another multimap. Subclasses should override
 * one or more methods to modify the behavior of the backing multimap as desired per the <a
 * href="http://en.wikipedia.org/wiki/Decorator_pattern">decorator pattern</a>.
 *
 * <p><b>{@code default} method warning:</b> This class does <i>not</i> forward calls to {@code

import java.util.Set;
import org.jspecify.annotations.Nullable;

/**
 * A multimap which forwards all its method calls to another multimap. Subclasses should override
 * one or more methods to modify the behavior of the backing multimap as desired per the <a
 * href="http://en.wikipedia.org/wiki/Decorator_pattern">decorator pattern</a>.
 *
 * <p><b>{@code default} method warning:</b> This class does <i>not</i> forward calls to {@code