XmlAdapter определяет два абстрактных метода, а также конструктор по умолчанию без аргумента arg.
Unmarshaller s и Marshaller s создает экземпляры XmlAdapter с использованием конструктора по умолчанию (если только экземпляр не предоставляется с setAdapter).
Сначала я думал, что причина заключалась в том, что для Marshaller и Unmarshaller всегда существует конструктор по умолчанию без аргументов, но, как вы сказали, если бы подкласс XmlAdapter объявил конструктор без аргументов, это сделало бы конструктором по умолчанию XmlAdapter невидимый. Фактически, реализация XmlAdapter, которая добавляла конструктор с аргументами и не предоставляла конструктор без аргументов, приводила к сбою операции Marshall / Unmarshall, если только экземпляры не предоставлены с помощью методов setAdapter.
Таким образом, нет практической причины использовать и абстрагировать класс вместо интерфейса с текущей реализацией .
Полагаю, это было дизайнерское решение, поскольку использование абстрактного класса лучше всего подходит с точки зрения эволюции. Например, если в какой-то момент какая-то общая инициализация требуется в конструкторе, она может быть реализована в пустом конструкторе. Или если метод, который требуется в XmlAdapter для маршалинга списка объектов, он может быть реализован с помощью чего-то вроде этого:
public List<ValueType> marshalList(List<BoundType> list) throws Exception {
List<ValueType> result = new ArrayList<>();
for (BoundType b: list) {
result.add(marshal(b));
}
return result;
}
И внутренние классы JAXB могут использовать этот метод без необходимости изменять какие-либо реализации адаптера.