Заставить класс переопределить метод .equals

Нет, не можешь. Однако вы можете использовать абстрактный базовый класс вместо интерфейса и сделать equals() абстрактным:

abstract class Command {
   // put other methods from Command interface here

   public abstract boolean equals(Object other);
   public abstract int hashCode();
}

Подклассы Command должны затем предоставлять свои собственные методы equals и hashCode.

Обычно плохая практика заставлять пользователей API расширять базовый класс, но в этом случае это может быть оправдано. Кроме того, если вы сделаете Command абстрактный базовый класс вместо интерфейса, вместо того, чтобы вводить искусственный базовый класс в дополнение к командному интерфейсу, тогда нет риска, что пользователи вашего API ошибутся.

Можете ли вы расширить свои объекты из абстрактного XObject, а не из java.lang.Object?

public abstract class XObject
 extends Object
{
@Override
public abstract boolean equals(Object o);
}

Абстрактные классы не будут работать, если у вас есть внук, поскольку его отец уже переопределил методы equals и hashCode, и тогда у вас снова возникнет проблема.

Попробуйте использовать аннотации и APT (http://docs.oracle.com/javase/1.5.0/docs/guide/apt/GettingStarted.html), чтобы это сделать.

Это было бы возможно, только если бы Command была интерфейсом или абстрактным классом, где equals (..) - это метод, объявленный как абстрактный.

Проблема в том, что Object, который является суперклассом всех объектов, уже определяет этот метод.

Если вы хотите указать, что это проблема (во время выполнения), вы можете создать исключение, чтобы пользователи вашего API переопределили его. Но это невозможно во время компиляции, по крайней мере, насколько мне известно.

Попробуйте обойти это, используя метод, специфичный для API, например CommandEquals. Другой вариант (как уже упоминалось) - расширить другой класс, который определяет абстрактный метод Equals.

Вы можете создать boolean myEquals() в interface Command и создать адаптер следующим образом:

class MyAdapter{
  Command c;
  boolean equals(Object x) {
    return c.myEquals((Command)x);
  }
}

Тогда вы просто используете map.put(key, new MyAdapter(command)) вместо map.put(key, command)

Что ж, если вам нужна проверка во время выполнения, вы можете сделать что-то вроде:

    interface Foo{

}
class A implements Foo {

}
class B implements Foo {
    @Override
    public boolean equals(Object obj) {
        return super.equals(obj);
    }
}

public static void main(String[] args) {
    Class<A> clazzA = A.class;
    Class<B> clazzB = B.class;

    Class<Object> objectClass = Object.class;
    try {
        Method methodFromObject = objectClass.getMethod("equals",Object.class);
        Method methodFromA = clazzA.getMethod("equals",Object.class);
        Method methodFromB = clazzB.getMethod("equals",Object.class);
        System.out.println("Object == A" + methodFromObject.equals(methodFromA));
        System.out.println("Object == B" + methodFromObject.equals(methodFromB));
    } catch (SecurityException e) {
        e.printStackTrace();
    } catch (NoSuchMethodException e) {
        e.printStackTrace();
    }
}

Напечатает true для первого и false для второго. Если вы хотите, чтобы время компиляции выглядело так, будто единственный вариант - создать аннотацию и использовать инструмент обработки аннотаций, чтобы проверить, что все аннотированные классы переопределяют равны.

Поскольку equals() унаследован от Object, я сомневаюсь, что вы действительно не можете заставить это, поскольку для каждого типа доступна автоматическая унаследованная реализация equals().

Я не думаю, что можно принудительно переопределить равные значения, поскольку это происходит из класса Object.

В соответствующей заметке обратите внимание, что вам нужно переопределить метод hashCode из класса Object, когда вы переопределяете equals. Это становится особенно важным, если вы собираетесь использовать экземпляры своих классов в качестве ключей Map. Проверьте эту статью: http://www.artima.com/lejava/articles/equality.html, который дает некоторые подсказки о том, как правильно переопределить равно

Как уже объяснялось в других ответах, нет, вы не можете заставить то, что вы пытаетесь сделать.

Одна вещь, которая может работать «достаточно», - это определить второй интерфейс, назовите его MappableCommand.

public interface MappableCommand 
{

}

В документации по этому интерфейсу укажите, что класс должен реализовывать этот (пустой) интерфейс только в том случае, если разработчик класса учел заявленные вами требования.

Затем вы можете установить тип значения вашей карты на MappableCommand, и только MappableCommands смогут быть добавлены на карту.

Это похоже на логику, по которой нужно реализовать (пустой) интерфейс Serializable для классов, которые могут быть сериализованы с помощью механизмов сериализации по умолчанию Java.

Если это не сработает, возможно, вам придется довольствоваться ошибкой времени выполнения;

Поддельное редактирование:

Если вы хотите сделать это требование более очевидным, вы можете определить новый интерфейс таким образом

public interface MappableCommand 
{

    public void iOverrodeTheEqualsMethod();

    public void seriouslyIPromiseThatIOverrodeIt();

}

Вот вариант некоторых других предлагаемых решений:

public abstract class CommandOverridingEquals implements Command {
    public abstract boolean equals(Object other);
    public abstract int hashcode();
}

Map<String, CommandOverridingEquals> map = 
    new HashMap<String, CommandOverridingEquals>();

Или, если вы действительно хотите быть уверенным, используйте проверенную хэш-карту; например

Map<String, CommandOverridingEquals> map = Collections.checkedMap(
    new HashMap<String, Command>(),
    String.class, CommandOverridingEquals.class);

Но что бы вы ни делали, вы не можете помешать кому-то сделать это:

public class AntiFascistCommand extends CommandOverridingEquals {
    public boolean equals(Object other) { return super.equals(other); }
    public int hashcode() { return super.hashcode(); }
    ...
}

Я склонен думать, что подобные вещи вызовут проблемы в будущем. Например, предположим, что у меня есть группа существующих классов команд, которые расширяют какой-то другой базовый класс и (кстати) переопределяют equals и hashcode предписанным способом. Проблема в том, что я не могу использовать эти классы. Вместо этого я вынужден заново реализовать их или написать кучу оберток.

ИМО, это плохая идея - пытаться принудить разработчика к конкретному шаблону реализации. Было бы лучше поместить несколько серьезных предупреждений в Javadocs и положиться на разработчиков, которые поступят правильно.

Можно ли добавить свой java.util.comparator к рассматриваемой карте?