* Returns the {@link Method} instance for {@link #testPutAll_nullKeyUnsupported()} so that tests
   * can suppress it with {@code FeatureSpecificTestSuiteBuilder.suppressing()} until <a
   * href="https://bugs.openjdk.org/browse/JDK-5045147">JDK-5045147</a> is fixed.
   */
  @J2ktIncompatible
  @GwtIncompatible // reflection
  public static Method getPutAllNullKeyUnsupportedMethod() {

  }

  @J2ktIncompatible
  @GwtIncompatible // SerializableTester
  public void testDifferentComparator_serialization() {
    // don't use Collections.reverseOrder(); it didn't reserialize to the same instance in JDK5
    Comparator<Comparable<?>> comparator = Ordering.natural().reverse();
    SortedSet<String> set =
        new ImmutableSortedSet.Builder<String>(comparator).add("a", "b", "c").build();

   *       </ul>
   *   <li>another java.util.Map delegate implementation. In most modern JDKs, normal java.util hash
   *       collections intelligently fall back to a binary search tree if hash table collisions are
   *       detected. Rather than going to all the trouble of reimplementing this ourselves, we
   *       simply switch over to use the JDK implementation wholesale if probable hash flooding is

  @Override
  public @Nullable V replace(K key, V value) {
    return delegate().replace(key, value);
  }

  @CanIgnoreReturnValue
  @Override
  @SuppressWarnings("nullness") // https://github.com/jspecify/jdk/issues/118
  public boolean replace(K key, V oldValue, V newValue) {
    return delegate().replace(key, oldValue, newValue);
  }

import com.google.common.annotations.GwtIncompatible;
import com.google.common.annotations.J2ktIncompatible;
import java.util.Set;
import org.jspecify.annotations.Nullable;

/**
 * ImmutableSet implementation backed by a JDK HashSet, used to defend against apparent hash
 * flooding. This implementation is never used on the GWT client side.
 *
 * @author Louis Wasserman
 */
@GwtIncompatible

   * {@link java.util.TreeMap} can suppress it with {@code
   * FeatureSpecificTestSuiteBuilder.suppressing()} until <a
   * href="https://bugs.openjdk.org/browse/JDK-5045147">JDK-5045147</a> is fixed.
   */
  @J2ktIncompatible
  @GwtIncompatible // reflection
  public static Method getPutNullKeyUnsupportedMethod() {
    return getMethod(MapPutTester.class, "testPut_nullKeyUnsupported");

 * <p>In light of the significant enhancements to {@code Comparator} in Java 8, the overwhelming
 * majority of usages of {@code Ordering} can be written using only built-in JDK APIs. This class is
 * intended to "fill the gap" and provide those features of {@code Ordering} not already provided by
 * the JDK.
 *
 * @since 21.0
 * @author Louis Wasserman
 */
@GwtCompatible
public final class Comparators {
  private Comparators() {}

  /**

 * License along with this library; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */
package jcifs;

/**
 * Runtime exception indicating that the JDK does not support the cryptographic primitives that we use.
 *
 * @author mbechler
 *
 */
public class CIFSUnsupportedCryptoException extends RuntimeCIFSException {

    /**
     *
     */

   *       </ul>
   *   <li>another java.util.Set delegate implementation. In most modern JDKs, normal java.util hash
   *       collections intelligently fall back to a binary search tree if hash table collisions are
   *       detected. Rather than going to all the trouble of reimplementing this ourselves, we
   *       simply switch over to use the JDK implementation wholesale if probable hash flooding is

        }
        return sb.toString();
      }
    },
    // It really seems like this should be faster than TO_BYTE_ARRAY_NEW_STRING.  But it just isn't
    // my best guess is that the jdk authors have spent more time optimizing that callpath than this
    // one. (StringCoding$StringDecoder vs. StreamDecoder).  StringCoding has a ton of special cases