На самом деле вы должны иметь как конструктор без аргументов, так и методы получения и установки. Требования указаны в разделе 2.1 спецификации .
Требование конструктора без аргументов найдено на странице 17 в моей копии:
Класс сущности должен иметь без аргументов
конструктор. Класс сущности может иметь
и другие конструкторы. Без арг
конструктор должен быть публичным или
защищенный.
Страница 18 содержит требования к методам доступа:
Постоянное состояние объекта
представлены переменными экземпляра,
который может соответствовать Java-бобам
свойства. Переменная экземпляра может
быть доступным только изнутри
методы организации по
Сам экземпляр сущности. Пример
переменные не должны быть доступны
клиенты организации. Штат
сущность доступна для клиентов
только через средство доступа к объекту
методы (методы получения / установки) или
другие методы ведения бизнеса. Пример
переменные должны быть приватными, защищенными,
или видимость пакета.
Доступ к полю и собственности указывает, как поставщик JPA взаимодействует с вашей сущностью, а не как клиентское приложение взаимодействует с ней. Клиент всегда должен использовать методы get и set.
Некоторые поставщики JPA более снисходительны в этих требованиях, и вы можете сделать конструктор частным (как предложено выше) с конкретным поставщиком. Приложение может быть не переносимым, поэтому вы можете быть удивлены, если будете мигрировать в будущем.
Так что я бы не рекомендовал полностью опускать методы. Чтобы решить эту проблему, я бы пометил общедоступный no-arg ctor как устаревший (поместите что-то в javadoc о том, что это только для использования JPA-провайдером) Методы set могут содержать логику, которую вы хотите поддерживать ваши инварианты.
Это не идеально, но это должно предотвратить случайное использование неверного ctor (я предполагаю, что у вас есть ctor, который устанавливает инварианты).